Reference types vs value types

All C# types fall into the following categories:

  • Value types
  • Reference types
  • Generic type parameters
  • Pointer types

Value types comprise most built-in types (specifically, all numeric types, the char type, and the bool type) as well as custom struct and enum types.

Reference types comprise all class, array, delegate, and interface types. (This includes the predefined string type.) The fundamental difference between value types and reference types is how they are handled in memory.

Continue reading “Reference types vs value types”

Implementing Value Types – Best Practices

When implementing you own struct you should take into consideration the following:

  • Use structs when you intend to create a great many of them
  • structs should be small. Large structs (i.e. structs with many fields) would lead to poor performance, since structs are copied each time.
  • Use structs when you require high density memory collections.  Structs have have a much simpler memory layout and offer excellent memory density and lack of overhead
  • Override structs Equals(…) method and implement IEquitable<T> interface to  avoid boxing.
  • Overload == and != operators
  • Override GetHashCode method.
  • structs should almost always be immutable. Actually I’ll go further and say always. Mutable structs could lead to confusion if declared as readonly. Any modifications to a mutable readonly struct will be ignored, making it a very difficult bug to spot.

Structs have also got their own limitations. Since they don’t have an object header, you cannot for example use a lock(…) on a struct since this  will result on compile time error. However Monitor.Enter(…) accepts any object, structs included, thus leading to a bug. The value  of the struct will be boxed each time and that would be equivalent to having no lock at all!

Troubleshootng Deadlocks in .NET Applications

What do you do when your application become unresponsive due to potential deadlocks?

I think the first thing to do is to identify exactly where the application hangs due to a deadlock. To do this you should replace the lock(…) statement with it’s equivalent Monitor.Enter(…)/Monitor.Exit(…). Monitor has an argument which alloys you to specify timeout. So when you change the suspicious code with Monitor.Enter(…)/Monitor.Exit(…) while specifying the timeout, the code will throw the exception when this timeout has exceeded the specified timeout. While this doesn’t solve the dead lock issue, it points you to the location within you code where there is a possible issue.

Additionally, you need to make sure that the locks are taken in the same order i.e,


This is only for troubleshooting purposes. You should revert back to normal locking when the issue is found and fixed.

One easy thing you can do is to pause execution within Visual Studio by pressing on the pause button and then see what each thread is up to.

You also might want to consider more granular locking primitives, such ReadWriterLockerSlim and refactor you code to use less locking.

Whenever you feel like putting a lock always question yourself if this is the right thing to do and if there is a way doing this without locking all together

string.Intern(…) – Minimising Memory Footprint

I had a one particular view (in the UI) that loaded denormalised data with many repetitive strings. There was nothing much we could do to minimise the volume of the data loaded, however during profiling I realised that most memory was consumer by strings, and most of them were the same.

I remembered a feature of a ‘string’ to intern the value i.e. two or more string having the same value would point to the same memory location without duplication. Applying this technique allowed me to save about 2/3 of the memory consumed. There was one downside though, this memory would never be reclaimed.

So now I’m thinking of writing my own interning using WeakReference

Blog at

Up ↑