Re: Performance tuning

To follow up a little, performance tuning is a phased approach as well.
You have to look at big picture issues before you dig down into
micro-optimizations like you are asking about now. Like Marc said, use a
profiler, see what the bottlenecks in your application are, and then address
those. If you are performance tuning, then you have a goal in mind for what
is acceptable for your application in terms of performance (if you don't
have a goal, then performance tuning for the sake of performance tuning is a
waste here since you are more than likely going to compromise the
maintainability and design of the code in the process).

For switch statements, once you have more than a few cases, the C#
compiler turns it into a Hashtable (possibly a Dictionary in .NET 2.0 and
beyond) which is used for the switch. For very large switch statements, my
guess is that this is faster. Also, this should be faster than repeated
if/then statements as well.

I agree that unsafe is going to do much for you here.

IIRC, the speed of invoking delegates was increased dramatically with
..NET 2.0. Making calls on interfaces/class instances is always going to be
faster, but I think that calling delegates might be much closer to the speed
of calling a member directly. Of course, if you are doing this over a
massive number of iterations, this small amount can add up.

Using "yield" is always going to add overhead. When you use "yield" for
an IEnumerable implementation, the compiler is generating a state machine
for you in the background, and that's always going to cost more resources
than doing it yourself.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx

"Marc Gravell" <marc.gravell@xxxxxxxxx> wrote in message
news:ONwUPTjkHHA.4624@xxxxxxxxxxxxxxxxxxxxxxx
Use a decent profiler and find out. Otherwise you are simply guessing, and
could be having little effect, or making things worse. In most cases, the
performance isn't down to micro-optimisations such as if/else vs switch,
but rather down to bulk algorithms e.g. looping over a pair of collections
rather than using a dictionary for "exists" etc.

For specifics; I recall reading an article demonstrating that switch was
*marginally* quicker, but barely by enough margin to warrant the risks
from an edit... "unsafe" would do very little unless you actually use
unsafe functionality inside the block. For sorting, the interface-based
approach (IComparer<T>) /may/ be quicker than delegates - but don't trust
anybody: rig a test harness and find out, or profile your app. As for
exceptions - well, my code can screw things up very quickly indeed if I
don't correctly handle error conditions ;-p

Marc



.