There is going to be little difference in terms of the compiled results.
The main difference is that any arithmetic operation within the checked
block will use a different IL instruction. There aren't more instructions, just different ones. Instead of mul
, you get mul.ovf
- instead of add
, you get add.ovf
, etc.
Your version actually has slightly different behavior, however. Since you're putting the checked
block in the tigher scope, the variable increment (i++
) will still be unchecked. The original would have been checked all the way through, which means that the i++
could throw, not just the multiplication operation. This does mean your version is faster, but only because you're avoiding the overflow checks and changing the resulting behavior, not because of the scope change.
Is the presence of it inside the loop causing some underlying CLR code to be generated repeatedly?
No, it just means those IL instructions inside of that scope will get the different IL operation codes with overflow checks instead of the standard ones.
Or is there no overhead having it inside the loop?
There is no overhead (other than the extra overhead of the checks in the instructions itself).