The object of the tests was not how to eek out every last bit of performance out of .net. The code was specifically written in normal way to illustrate that .net has good performance without doing strange things.

Something that I forgot to mention as well was that I ran all the tests in debug mode, not release mode — which would have helped performance even more.

As for you point about .net is not suitable for real time — funny, I know a number of guys who did just that with .net in a large manufacturing environment. I’ll have to tell them their working implementation wont work.

String creation in .net is different than in C in that .net string are immutable and are a managed resource.

If I do a simple string concatenation:
string a = “abc”;
string b = “def”

a = a b;

In C#, in the a = a b I’m creating a new string that consists of the old a and b. Also, if I have two string variables with the same text in them, then those variables are actually pointing to the same string. That is part of being a managed resource.

I put the string concatenation in there to give things a small “real-world” flavor, knowing full well it would slow things down a bit. After all, to just create 1,000,000 empty objects isn’t saying too much.

But, as a test, I created 1,000,000 strings in 1.6 seconds using the same test. I did a second test as well where I pre-initialized the collection, thinking this would improve performance — it did not. Not noticeably anyway.

As for the time difference between 1000 and 10,000…I can’t completely explain that one. My thought is that it happens so fast what you are seeing is just the ramp up time for the method. Or it could be my timing mechanism was not as precise as it is made out to be.

You are right. The constructor on list has an overload which could have saved you all the “array” copying that goes on in the background. This would also help you avoid the exponential time curve.

>2. That .net is too inefficient to do any real work

If real work means web server to handle thousands of simultaneous requests with immediate responses, you have probably just proved above that .net is too slow to do any ‘real’ work. .Net is also often unsuited for real-time apps.

Also keep in mind when testing that the GC will only kick in after you have been running for a while – performance will drop even more at that point. (run longer tests)

Second, based on your results, I’ve decided that if I’m going to create 1000 objects, I might as well create 10,000. After all, 10,000 is 10x better than 1000 and I get it for the same cost