Dotmad.net

The application I’m working on is a C4I, GIS based application, originally written in framework 1.1.

Recently we did several tests to prove the improvements derived from upgrading to framework 2.0 (or 3.0) without doing major changes in the base code. The performance improvement focus was on switching to Generics for collections containing value types.

Possible pitfalls - mostly the usage of Hashtable and other 1.1 collections, which tend to return NULL when the key is not found. Unlike them, the Dictionary class and similar generic collections tend to throw exceptions if the key is not found. This requires adding calls to the ContainsKey method to prevent these exceptions. Nothing complicated, but a lot of manual labour.

Performance improvements (also with some minor refactoring):

• CPU usage in heavy-load-scenarios was reduced by 10-20%
• Time in GC (as measured by perfmon) was reduced to half of the previous value

The Singleton pattern is very well known to .Net developers, especially the static implementation.
Lately I have encountered several versions of the generic Singleton, among them the one described in Arnon’s post.

However, there is one possible pitfall to this approach, as it makes this code possible:
Singleton<myclass> obj = Singleton<myclass>.Instance;
MyClass obj2 = new MyClass();

While I personally like the idea of having the freedom to use the same class in two different ways throughout the application, I know some people like their Singletons - well, single.
On the other hand, if you write a class from the start as a Singleton this is not an issue.

There is an inherit risk in decoupling a class from it’s expected behavior, so take this into consideration before using this pattern.