Release it! - some loose thoughts

I’ve been trying to finish that book for quite some time. It was difficult :) because it is a book that you can read chapter by chapter without losing the plot and hence it’s easy to abandon it every now and then. Anyway, I managed to finish it this week and I have to say that I haven’t really learnt anything new. This doesn’t mean that it was a waste of time. On the contrary, after reading it I’m more confident that what I’ve been doing is right and I’m not some kind of weirdo that demands the impossible :). It’s definitively a must read for developers that haven’t worked in 24/7 environment where part of their job is to be on call for a week every month or two. When you can get a call at 3 am you design your software in a little bit different way :). I will dedicate a separate post to that topic.
There is one thing in the book that I disagree with though. Page 199, Michael recommends to use SoftReference when implementing a cache in Java. The counterpart of SoftReference in .NET world is WeakReference. I think that is a very bad idea. The most important part of every caching solution is its expiration policy which would translate to a simple question – when does the data need to be refreshed? GC operates at a very low level and it doesn’t have enough information to make an informed decision. Let me give you an example. Let’s say we have 2 arrays of integers(System.Int32). Both of them 1000 elements long and it takes 10 ms to fill the first one and 100 sec to fill the second one and they both need to be refreshed once an hour. From GC perspective they are basically the same objects. It doesn’t matter which one gets collected as in both cases GC will reclaim 4000 bytes. This is not true from the application perspective. If GC decides to release often the memory associated with the second array the application will crawl. If not it will be lightning fast. What if the GC implementation changes and after upgrade to the next version of the runtime the performance of the app changes completely. I wouldn’t like to debug this problem. In other words, you can’t build a solution that needs to be predictable(cache expiration policy) based on a component (GC) that is beyond your control.

Great book: C# via CLR

As I mentioned earlier I always wanted to read C# via CLR by Jeffrey Richter. Finally I got it a few months ago and while I was sick I read it. I think it's just brilliant because:

• I like the way Jeffery explains problems.He is strict and precise whenever it's needed but no more.
• As far as I know he is not a Microsoft employee which lets him express criticism of everything that deserves it.
• It reveals lots of things that you will never be aware of unless you start thinking in an illogical way. Unfortunately CLR and/or C# not always behave in a predictable way.
• The books touches nearly all the .NET internals that you can come across during your everyday job as long as you don't work on compilers and runtimes :).