Platform: .NET Framework 3.5 SP1 on x32
Are there any performance issues regarding leaving an empty statement (";", by itself) in code?
And to be marked as an answer would you also teach a man (me? and other people reading this) to fish? Meaning, how to figure out there is a performance issue with it?
I can't imagine any case in which a compiler wouldn't simply optimize an empty statement away. It certainly wouldn't generate instructions that mean anything other than "do nothing". If you think there's a performance issue with this, chances are good that it's something else.
The easiest way to see if there would be a performance issue (since I don't think there would be) is to run the debugger and see if that line is executed. if it is executed, try to get to the assembly behind that statement, as that would give you an indication on how many instructions result from that statement. Chances are though, it is a no-op, which is just a clock tick.
1) Use a tool like ildasm or .NET Reflector to look inside the assembly that is generated and see what IL instructions are associated with the ";" empty statement (if any at all; they might get optimized away into nothing.)
2) Use a profiler to run a huge loop with a bunch of ";"s included inside other code, and then try it without the ";"s and see if there's a difference.
(Without doing either of these I'd bet quite a lot that it's optimized away and produces no IL (or some kind of no-op instruction -- pardon my IL ignorance.))
The empty statement yields the nop IL code, so you can have as many as you like as they are removed by the JIT compiler.
I do not expect a performance hit.
You can check this by inspecting the generated IL code for a C# program with and without empty statements. You may use .NET reflector (www.redgate.com) to inspect the IL. If the same IL is generated, there cannot be a performance hit.
The simplest way to measure performance is to write your code and run it multiple times whilst timing it.
As for this scenario, I do not believe you will lose any code performance for having empty lines, however, it may affect your compile times, (albeit negligable).
In the spirit of teaching you to fish,
1) examine the assembly, as was suggested
2) run a big loop & time it (a wristwatch is a perfectly good tool)
3) single-step it in the disassembly window (similar to 1).
If you are concerned about performance, the wrong thing to do is to start guessing about language constructs. The right thing to do is to diagnose, and let the program tell you what is taking time, as in
As an alternate way to test performance:
Start out with:
// breakpoint here
int breakpoint1 = 0;
for (int i = 0; i <= 1000; i++)
{
// test operation here
;
}
// breakpoint here
int breakpoint2 = 0;
Run to the first break point, then press F5 and count in your head. If it goes too fast then change the loop to 10,000 and try again. If it's too fast increase it to 100,000 and try again.