0

I was messing around my IL code inside of my dll file (just for learning purposes). I wanted to see what would happen if I injected my own IL code, for example... I threw in a box call: IL_9999: box !T. I'm wondering if the offset value actually matters though...

Does an IL offset of 9999 cost more in terms of performance than an IL offset of say 1000? My guess is it doesn't since the compiler itself, while going in order, skips offsets:

IL_000d:  ldc.i4.3
IL_000e:  box        [mscorlib]System.Int32
IL_0013:  call       instance int32 [mscorlib]System.Enum::CompareTo(object)
IL_0018:  call       void [mscorlib]System.Console::WriteLine(int32)
IL_001d:  nop

Also, does it harm my application if my IL offset of 9999 is thrown into the middle of these other IL offset calls that are far lower in value?

myermian
  • 31,823
  • 24
  • 123
  • 215
  • 4
    This makes no sense, the IL_000d: annotation is something that a disassembler shows. You don't actually write it yourself when you write your own IL or use Reflection.Emit – Hans Passant Nov 30 '12 at 21:31
  • @HansPassant: Sorry if I wasn't clear... I used a disassembler to get to my dll's IL. That is where I was playing around. – myermian Nov 30 '12 at 21:42
  • @m-y But disassembler usually won't let you modify the code. – svick Nov 30 '12 at 21:46
  • @svick: I modified the disassembled code, then used ilasm.exe to reassemble it back into a dll. So I sorta can modify the code :) – myermian Nov 30 '12 at 22:04
  • That notation simply refers to the offset of the code, explaining how that offset is obtained is a bit more complex than "is it slower". In either case it is safest to not muck with the offsets, or even better, create you own IL file without offsets explicitly specified. – Guvante Dec 01 '12 at 01:29

1 Answers1

4

All of those IL_XXXX: are not actually offsets, they are labels. It's just that decompilers tend to add a label to each instruction and name it according to its offset. This is because label names are not preserved in the compiled code (and for example compiled C# probably wouldn't have meaningful label names even if they were preserved) and the decompiler needs to have at least some labels to use in branching instructions.

So, if you modify the “offset” and then compile the code using ilasm, you're actually not changing the code in any way. Because of that, it can't have any effect on performance.

One way you could verify this would be by decompiling your modified assembly again.

svick
  • 236,525
  • 50
  • 385
  • 514
  • Ahh, you are correct sir. I decompiled my library after compilation and the labels were reorganized (again). I guess the label is just that, a label and it doesn't seem to affect any performance at all. Thanks! – myermian Dec 02 '12 at 14:24