The .Net frog

I've heard from a co-worker that the readonly keyword was optimizing memory access and therefore quicker than a normal field access. I must admit that I found this assertion a bit surprising. My first bet would have been that the performance are identical with or without it (it's just a compiler check, but it doesn't result in any change at execution). If wrong, I then would have bet on a slower access (I would expect the CLR to do some checks when accessing the field). Let's see if I'm mistaken :).

Unfortunately for me, I didn't find anything to confirm or not my theories, so I decided to do my own micro-benchmark.

I measured the time spent for 3 main scenarios, with a read only field and without it:
- Scenario 1: Creating an object
- Scenario 2: Accessing the field
- Scenario 3: Creating an object and accessing the field

I executed this code 1,000,000,000 times for each scenario and ran each scenario 10 times on 4 different PC to get a meaningful average. For each test, I excluded the top and bottom result.
The code (in C#, .NET 2.0) is available here (It is duplicated for each test, I know it's horrible, my apologies :)), and the results here.

Each test looks like that (with sligh modifications of course):

_streamWriter.WriteLine();
_streamWriter.WriteLine("Obj creation & access in loop");
for (int j = 0; j < _numberOfTestExecutions; j++)
{
	Poco poco = new Poco();
 
	Stopwatch watch = new Stopwatch();
	watch.Start();
	for (int i = 0; i < _numberOfIterationPerTest; i++)
	{
		ReadOnlyField objReadOnlyField = new ReadOnlyField(poco);
		Poco myCopyOfPoco = objReadOnlyField.Poco;
	}
	watch.Stop();
	_streamWriter.Write(watch.ElapsedMilliseconds + ";");
 
	watch.Reset();
	watch.Start();
	for (int i = 0; i < _numberOfIterationPerTest; i++)
	{
		ReadWriteField objReadWriteField = new ReadWriteField(poco);
		Poco myCopyOfPoco = objReadOnlyField.Poco;
	}
	watch.Stop();
	_streamWriter.WriteLine(watch.ElapsedMilliseconds);
}

Here are the raw numbers:

Scenario 1: Creating an object
- read only: 25172ms
- read write: 24983ms
Read only is in average 0.76% slower than read write.

Scenario 2: Accessing the field
- read only: 6437ms
- read write: 6449ms
Read only is in average 0.19% quicker than read write.

Scenario 3: Creating an object and accessing the field
- read only: 19929ms
- read write: 19761ms
Read only is in average 0.85% slower than read write.

However, you can see greater differences by looking at the results for each computer. For instance, on the first PC I used (a core 2 duo, 2,8Ghz, DDR2 800Mhz), I have the following results:

- Scenario 1: Creating an object
Read only is in average 5.72% quicker than read write.
- Scenario 2: Accessing the field
Read only is in average 0.94% quicker than read write.
- Scenario 3: Creating an object and accessing the field
Read only is in average 2.28% quicker than read write.

And on a laptop (centrino 1,7ghz, DDR):
- Scenario 1: Creating an object
Read only is in average 6.34% slower than read write.
- Scenario 2: Accessing the field
Read only is in average 0.21% quicker than read write.
- Scenario 3: Creating an object and accessing the field
Read only is in average 3.01% slower than read write.

My (own) conclusions:
There seem to be a difference of performance involved by using the readonly keyword. The problem is that the impact is highly dependant on the hardware. On a PC with decent hardware, accessing a read only field is between 1% and 2.5% quicker than accessing a normal field. Object creation can be as much as 6% quicker. On lower-end hardware, the results are the opposite.
However, the tests have been made with very simple class, so keep in mind that in reality, the speed difference in object creation would have been smaller with classes that have more members.

As far as I'm concerned, I would not used the readonly keyword just for optimization purposes except for very demanding situations, and only after checking that it's actually quicker on the specifics machines where the software is going to run. So unless your application is:
- running on a very controlled environment with a very limited set of installations
- pseudo real-time or extremely sensible to performances
I don't think you should even wonder about the performance impact of readonly. There's probably hundreds of optimization that will be more effective before this one!

Finally, if you have any clue showing a different behaviour, please tell me about it and I will edit this post in consequence :). I'm specially interested in having benchmark with Xeon processors (unfortunately, I don't have access to one)

Part of a good object oriented design is to keep the objects in a correct state.

For instance, in the financial world, we have financial instruments called "derivatives". According to Wikipedia:

Derivatives are financial instruments whose value changes in response to the changes in underlying variables. The main types of derivatives are futures, forwards, options, and swaps.

In the real world, a derivative can't exist if there isn't an underlying financial instrument associated. A future on the dow jones could not have been created without the dow jones in the first place. If we want to represent a derivative in a software, we must make sure that we follow the same rule.

So let's assume that I have the following class:

class Derivative
{
	private string _name;
	private Instrument _underlyingInstrument ;
 
	public string Name
	{
		get { return _name; }
	}
 
	public Instrument UnderlyingInstrument
	{
		get { return _underlyingInstrument; }
	}
 
	public Derivative(string name, Instrument underlyingInstrument)
	{
		_name = name;
		_underlyingInstrument = underlyingInstrument;
	}
}

Any new developer on a project that uses this Derivative class will mentally map the Derivative class to the corresponding financial concept. He will expect the UnderlyingInstrument property to return a non-null object. However, this is not guaranteed in the current implementation. As a matter of fact, this class can currently be used to only convey the name of a Derivative. If we wanted to do that, we would need to create a new class for that purpose only. So in the mean time, if we want our code to stay in a maintainable state, we need to make sure that each Derivative object will be constructed correctly. If not, different people will make different usage of the class.

In that case, ensuring the correctness of the object can be done very easily. We just need to do a bit of Design By Contract. So our constructor will become:

public Derivative(string name, Instrument underlyingInstrument)
{
	if(name == null || name.Length == 0)
	{
		throw new Exception("The name of the derivative can't be null or empty");
	}
	else if(underlyingInstrument == null)
	{
		throw new Exception("A derivative must have an underlying instrument");
	}
 
        _name = name;
        _underlyingInstrument = underlyingInstrument ;
}

Now you're sure that a fellow developer won't use your object to do a weird thing :).

Of course, you can improve the clarity of this piece of code significantly by using various techniques and frameworks(including Debug.Assert or your own Assert class). For instance, I would write something like that:

public Derivative(string name, Instrument underlyingInstrument )
{
	Guard.Against(name == null, "The name of the derivative can't be null");
	Guard.Against(name.Length == 0, "The name of the derivative can't be empty");
	Guard.Against(underlyingInstrument == null, "The underlying instrument of the derivative can't be null");
 
	_name = name;
	_underlyingInstrument = underlyingInstrument;
}

But that's a topic for another day!

I did load testing last week on the component I am developing and found out that the performances were just miserable... It was barely capable of handling 60 messages per seconds which was: 1) bad and 2) surprising! (Basically it's doing some kind of real-time caching/transformation/redirection of messages).

I then spent 5mins in dotrace trying to get a picture of what was going on. I found that in the thread that is monitoring the queue and sending messages, I had used an instance of ManualResetEvent instead of AutoResetEvent.

If you never used them, these 2 classes allow you to send signals between 2 threads. That way, the "monitor" thread is not wasting any resources until it's notified by the other thread that there is something in the queue. For instance, Thread 1 will wait for a queue to be filled with something like that:

 
private AutoResetEvent _mySignal = new AutoResetEvent(false);
 
private void MonitorQueue()
{
	while(!monitorQueue)
	{
		_mySignal.WaitOne();
		GetItemsInTheQueueAndDoStuff();
	}
}

And thread 2 will inject data in the queue:

 
public void EnqueueItem(Item myItem)
{
	InsertInQueue(myItem);
	_mySignal.Set();
}
 

As I said, my problem is that I used a ManualResetEvent instead of an AutoResetEvent. These 2 classes are almost the same except that when you use ManualResetEvent, you need to reset the signal manually with mySignal.Reset();. In my case, instead of blocking on mySignal.WaitOne(); the code was constantly looping and using a lot of CPU!

I fixed it and reran the load testing: now I'm at 5000 messages per seconds at 40% CPU. Much better!

I've seen that kind of things in several codebases recently:

lock(this)
{
    // Do stuff...
}

Even if it perfectly works, this is a bad idea. You should never (or at least I can't think of a good reason!) lock on a public type, therefore including "this". There is a simple reason: you don't know what expectations the caller is doing.

Let's take a simple example. In the following code, we have a class that uses a lock on this (ClassThatLocksItself) and another class that is going to call it (CallerClass). When CallerClass calls ClassThatLocksItself, it's going to lock on the instance of ClassThatLocksItself.

    class Program
    {
        static void Main(string[] args)
        {
            ClassThatLocksItself myObj = new ClassThatLocksItself();
 
            CallerClass caller = new CallerClass(myObj);
            caller.LockTheObjectInAThread();
            Thread.Sleep(500);
 
            myObj.LockMe();
        }
    }
 
    class CallerClass
    {
        private ClassThatLocksItself _myObj;
        public CallerClass(ClassThatLocksItself myObj)
        {
            _myObj = myObj;
        }
 
        public void LockTheObjectInAThread()
        {
            ThreadPool.QueueUserWorkItem(LockTheObject);
        }
 
        public void LockTheObject(object state)
        {
            Console.WriteLine("Acquiring lock on the object");
            lock (_myObj)
            {
                Thread.Sleep(100000); // Do a long computation
            }
            Console.WriteLine("Releasing lock on the object");
        }
    }
 
    public class ClassThatLocksItself
    {
        public void LockMe()
        {
            Console.WriteLine("ClassThatLocksItself -- Trying to acquire lock on this");
            lock (this)
            {
                Console.WriteLine("ClassThatLocksItself -- lock on this acquired");
            }
            Console.WriteLine("ClassThatLocksItself -- lock on this released");
        }

If you try to execute this code, you'll notice that Console.WriteLine("ClassThatLocksItself -- lock on this acquired"); is only executed when LockTheObject() returns (here it takes 100 seconds). By using lock(this), you became dependant on externals and unknowns factors (in that case, the caller of your code decided to lock on your class). The situation is even a lot worse for developers who want to reuse your ClassThatLocksItself: they have no way of knowing that there can be a synchronisation problem unless they read the code of your class!

Now, try to guess what is going to happen if you change the implementation of LockTheObject with the following:

public void LockTheObject(object state)
        {
            Console.WriteLine("Acquiring lock on the object");
            lock (_myObj)
            {
                _myObj.LockMe(); // will not lock!
            }
            Console.WriteLine("Releasing lock on the object");
        }

Most of you will bet on a deadlock I guess. However, the CLR is intelligent enough to detect that when LockMe executes lock(this), the lock was already acquired by the caller. Therefore, it doesn't block on it. It makes the whole lock(this) thing very subtile: you'll only see a problem in some specific cases.

Continue Reading »

Hi guys, welcome on this new blog!

Like many people, I learned a lot by reading posts from various very good writers (Think Jeremy Miller, JP Boodhoo, Martin Fowler, and dozens of others!). Since I discovered their blogs, their knowledge has always been useful to me. Even if I don't know them personally, they helped me a lot in improving my skills as a developer. In a few words, I owe them a lot!

Starting this blog is a way to try repaying my debt to the community as a whole at my humble level. As a matter of fact, I feel that there's still a lot to do to improve the way we do software development. Even if there are some excellent books and articles available on internet, most people I've been working with have always been foreigners to topics such as design patterns, testing, agiles methodologies, etc. Even if I don't have the expertise of all the people above (and I also don't claim to master any of these topics myself!), hopefully, I'll be able to convey good practices and ideas too. Who knows, maybe I'll even make a small difference around me! :)

Let me also give you a quick background about myself. I'm a French guy working as a .NET developer in the financial industry. I spent the last year in London working for a hedge-fund, and I moved back to Paris in February where I started a new job in a consulting company. Before that, I was studying computer science in a French engineering school which also lead me to do several internships. I also started a company during that time but it's an old story! Bottom line: I'm still very young and I still have a lot to learn!

Finally, while I'm here, I also apologize in advance for all the spelling mistakes that I'll do in my posts. Please feel free to correct me whenever you spot one (that is probably every 5 words!).

See you!

By the way, I'm also opening a french version of this blog here: www.thedotnetfrog.fr