Why ninjas are cool

No. You are wrong. This is not yet another rant about why Dusk of Ninja & Brush is a totally awesome game. This is real ninja stuff! .NET ninja stuff – but you catch my drift.

Today I went to a Tech Talk at microsoft about ASP.NET performance. Usually these talks contain just enough to not be a complete waste of time – but they are seldomly totally awesome. Today was different. Today a ninja was doing the talk. The Ninja was Mads Kristensen. I have been reading his blog for a while, and knew that he was good. But seeing him live was a whole other ballgame. The dude knows his tech and how to present it.

First of all he cut straight to the chase saying that usually when you talk about ASP.NET optimization – or when MSDN does anyway – they talk about how optimize all the backend stuff. The point is that this matters – but not as much as you think. Usually that part of serving the page takes up less than 10% of the total time the page takes to load… What takes the other 90% is all the CSS, JS and image content stuff. So that is really where you want to optimize.

Taking it from there he ran at a gracefully fast ninja tempo through techniques like minifying, compression, outputcaching, http caching and a lot of other stuff. Techniques that I knew, but I am really underutilizing because they are somewhat hard to get into and get to work properly. Mads showed me that it was just because I was trying to use a screwdriver to drive in a nail. With a lot of handlers and helpers page, most of which were dead simple 1digit-liners, he transformed an albeit simple site page using ASP.NET AJAX, external CSS and JS from 18 HTTP requests and 200K down to 5 requests and 30K – 0K on following requests when cached. Yes – that is no content. Driving the YSlow score up to a whopping 93.

You of course have to use some thought on how to manage caching if you have a highly dynamic site. But with his handlers and helpers in that was pretty simple too. Bottom line – this can be used on almost any ASP.NET site with very little effort. I just can’t wait to get my hands on this code!

Mads. You are truly a ninja. Keep up the great work.

Global Game Jam 09 is over

…and it has been a blast. 48 hours of game making madness around the globe. I am really looking forward to seeing how much press this event generates and to see the games that have been created. Needless to see very few will have time to play all the games that the 1500 participants worldwide has made. Here we made a massive 29 different games – and we were 150 people. A quick calculation suggests that this will result in at least 250 games made this weekend. Mind boggling. Glad I have the badge and T to show that I was in the event.

So… You are waiting to hear about our game? We went with a safe kick-ass theme: Ninjas and Zombies. You can’t really go wrong there, can you? Our game is called Dusk of Ninja and Brush and it features the last minutes of our hero Ninja while he and his friend Brush is being overrun by zombies.

Won’t go into more detail in writing, because playing says more than 1 gazillion words. But since the Unity windows beta version we used does not have the ability to publish a web player, you’ll have to wait a few days. I promise I’ll get it ready as soon as I get a capable Unity version, and I’ll post the link to the game here.

StringBuilder and the immutability of strings

I had a discussion today with Robin, who claimed that there was several ways to break the immutability of strings in C# – most notably by using a StringBuilder to build the string in bits. I found that very unsettling, and decided to make my own tests to see what was happening. Here is a screenshot of the program and the results.

The results are pretty interesting, and not as unsettling as i had feared. It seems that immutability of the string is indeed broken for the string gotten from the StringBuilder as it is not the same reference to the string. This is at least what I thought was one of the porperties of string immutability in C#. Luckily both an Equals call and == report the strings as being the same.

What practical implications does this have? Obviously – do not rely on ReferenceEquals when testing string. But when would you do that. The only case I can think of right now is when testing:

Using “Assert.Same” (in xUnit – Assert.AreSame in NUnit), will fail. This is not something that I would normally do – I mostly use Equals and only Same when I really mean it. If you have a different strategy, maybe it is time to revisit it.

But what is really happening here?! You have to dig a litte bit to find out what is going on. In .NET strings are usually stored in the intern pool. This is the way to ensure immutability. This is true for all cases of literal strings at least. Even strings literals concatted with + have ths ability. But in some cases, apparently when strings are generated from char arrays, like when they come from interop or StringBuilder, strings will be put in the heap instead of the intern table. To the rescue comes the String.Intern() method which will correct all wrongs:

There. Now you know some more about the inner workings of strings. Lesson to be learned: Never ever use ReferenceEquals to compare strings. And if you are forced to – Intern them first.