On performance in .NET

[skiminog]

(This article was originally published at Blog - Alex (Oleksandr) Polozov. See On performance in .NET for more comments and better formatting.)

Formerly, when someone asked me “How to make my C# program faster?”, my go-to advice was:

1. Improve your computational complexity.
2. Switch to a native language.

Of these suggestions, step #1 should take care

Comments

[steer]

What profiling tools exist in the .NET world

Good post but I think this point should be right at the top before everything. If it's too slow put it through a profiler. A PhD student of my acquaintance had spent months (literally) working on different database access techniques that would theoretically bring his simulation of a 3D gaming environment down from O(n^2) to O(n log n) which seems like a big win. At my insistence after weeks of nagging he put it through a profiler. > 80% of his code time was executing the sqrt function. No joke -- it was all about working out distances between things and he was using the Euclidean metric via pythogoras as you do. (The sqrt was, in fact, unnecessary as he only wanted to know which was bigger).

[skiminog]

Profiling goes without saying: it you don't know exactly what your bottleneck it, you shouldn't be doing performance optimization in the first place. The point of this post is that in .NET your profiling often should answer very specific questions, and there are very specific tools and techniques that you should use to answer them. For example, often knowing that your code spends 80% time in a particular function is not enough. Assuming that you've already done complexity optimization (and this function is, in fact, necessary for the algorithm), it may turn out that the hidden reason why this function is so goddamn slow may be boxing, hidden gen-2 collections, or a bunch of cache misses. Only a specific profiler, such as PerfView, is going to show you such things, and only if you know where to look.

[steer]

Apologies, I 100% agree that it should go without saying and your article seems excellent technically. I only wrote what I did because I've encountered people (several, particularly starting out programmers in academia with a good grounding in O notation) who take your step one as actually being step one. You are also completely right that knowing where the code is can be far from the whole story.