Home > Computers and Internet > When eye candy can hurt

When eye candy can hurt

The phrase eye candy that I’m using here refers to when a programming language does things in the programmers behalf. An example for C# would be the lock statement. Everyone knows that when a lock statement gets complied, the compiler turns it into a try/finally block with a Monitor.Enter and Monitor.Exit call. A programmer can write it either way, but most everyone uses the lock statement, because it’s cleaner and more human readable.
I have just been caught off guard with how damaging a certain piece of C# .Net eye candy has been.
I have a little application which executes a series of permuations in parallel in an attempt to maximize the computing resources of the computer. When I profiled my application it was generally using all of the processor cores on the computer, but once in a while it was only using one core. All of the times when my applications CPU utilization dropped to one core I saw that the threads were blocked in the Garbage Collector as it was allocating new memory. I know that my application allocates a bunch of memory, but I figured I’d run the profiler in the memory allocation mode to find out if there was something being allocated that I wasn’t expecting; there was. My application was allocating a lot of WaitCallback’s.
If you look at the method signature for ThreadPool.QueueUserWorkItem you see that it takes a WaitCallback. But I was never giving it a WaitCallback object. I was just specifying a method name. The same method name, everytime. What’s happening is the complier is seeing my code and sees that I’m not passing a WaitCallback, but instead of erroring out it sees that I’m specifying a method whose signature matches a WaitCallback. So it creates a new WaitCallback at that point in the code. The end result is that everytime a queue’d up a call to the method a new object was being instantiated.
So in the constructor for the class I allocate a single instance of a WaitCallback. Then everywhere where I was calling QueueUserWorkItem for my evaluate method, instead of specifying the method I passed it the already instantiated WaitCallback. The result is more work on my part, less eye candy, but noticably better performance.
Before the change the profiler said that my application allocated 27,118,645 bytes. After the change it allocated 7,110,181 bytes. I’d say it’s worth the change.
Now am I going to stop using the eye candy of specifying a method instead of a delegate WaitCallback in my code? Most of the time, no. It’s rather conventient and usually doesn’t matter. But I’ll keep my eye out for those instances when it might.
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: