Justin Rogers

Hey Justin,

I also love making my code highly performant. But I tend to profile and count on the profiler to tell me where to spend my time. It's different if you are writing libraries. When implementing a library you have to think about the use cases. Collection classes of course need more care because by their nature they will be looping over items many times.

I notice in a previous post that you were factoring a loop into two loops one for a null comparison and one for non-null. I often find myself doing this in critical code. Today I came upon a case where I had a loop being called many millions of times that had many tests inside of it. Now I'm toying with the idea of using code emit to create the code for the loop so I can create a version without the tests taylored for the job I'm doing.

What do you think? Is this a brilliant idea or a terrible one? The down-side is that debug may be harder but the performance should be terrific.

Hi Justin, Mythical Man Month by Fred Brooks is one reference for those claims.

I believe it. As a senior developer manager/architect, I'm currently trying to recruit four new developers. You'd think it would be easy given all the rhetoric about unemployed programmers, but the disparity in quality between any two candidates are very high. I wrote a couple of quick posts about my current experience.

http://haacked.com/archive/2004/10/01/1294.aspx http://haacked.com/archive/2004/10/06/1308.aspx

I reckon the major difference is not in performance of code produced but in actual productivity. The two key abilities, to understand the problem and create a solution which fits into the existing code environment in a non-breaking fashion, are scarce.

Trying to focus on performance as the first thing almost always leads to mistakes and overwrought code which needs to be rewritten when the requirements are more clear - which they always are after every iteration, at any level.

-- Barry Kelly

Dan Golick: dynamic code generation can be a huge win if the compiled code is then static and reusable and the cost of producing it can be amortized over all the times it is used.

A project I'm working on had an inner loop which used Activator.CreateInstance() to construct objects which were loaded up from an assembly at run-time. Throughput doubled when I did 4 things:

1) Created an interface with a method which had the same signature as the constructor call.

2) Dynamically generated a class which implemented the interface and called the constructor which Activator would have called via reflection.

3) Constructed a static instance (using Activator, ironically) of the generated class.

4) Replaced the single call to Activator.CreateInstance() with a call to the appropriate method of the appropriate generated class's instance.

The reason throughput doubled was that (in a sample small test run) 10 seconds of 20 seconds was taken up inside the Activator.CreateInstance() method. The construction code fell off the radar after the optimization.

-- Barry Kelly

Dan: Can conditional compilation work in this case? I definitely try to refactor and remove the excess code and this can often be a way to put the checks in and remove them later.

Haacked: Always looking for contracts if you need a surgeon for some code. As you can see from the blog I'm fairly focused on what I like to do, but I have a broad range of talents, and a fairly decent resume (see the News section). I also have doc format available if you want to hit that contact button at the top of the page. I had someone WRITE the doc version, so I think they caught all of my spelling errors (though I have added a line or two).

Barry 1: I like to make the following comment whenever I'm asked how long it takes me to do an in-depth performance analysis. "The more you work something, the better, faster, and more efficient you become at it". This is a very general concept, but it applies to everything that one might do. There is the basic factor of intelligence that you can layer on top of this for the *figuring things out* part, but once we all breach the 168 mark and get into hard to measure ranges you can toss that out as well. It takes me the same amount of time to write performant code as it does for me to write normal code. That is because in my head the algorithm comes out quickly (pardon the odd joke) without thought of refactoring really. Often times I do go back later just to double check, but I don't think I sacrifice any productivity for it. I often think managers don't realize you can get a secure, performant, productive developer in a single package any more. Putting all three of those things together probably meets at least the three dev requirement. I figured those three things were the reason I could put the senior in my title.

Barry 2: For your interface problem, the binding in Activator.CreateInstance can be pretty nasty. There are other options though, including finding the constructor you need through reflection and invoking it directly while caching the ConstructorInfo. A static factory method (a method that returns an instance) is a second option. Not knowing your scenario, you may have already found your best option.

     Good idea!

P.S. A U realy girl?