Does variable name length matter for performance C#?

I've been wondering if using long descriptive variable names in WinForms C# matters for performa开发者_运维技巧nce? I'm asking this question since in AutoIt v3 (interpreted language) it was brought up that having variables with short names like aa instead of veryLongVariableName is much much faster (when program is bigger then 5 liner). I'm wondering if it's the same in C#?

No it doesn't. Compiler actually does not save original variable names, you can look at the IL code of any compiled assembly with disassembler.

It is a key difference between a compiler and an interpreter. An interpreter does an identifier name lookup while it is interpreting code. If that name lookup happens inside a loop that executes many times, the time needed for that lookup can matter. Longer names require more time.

The C# compiler eliminates identifier names in two distinct stages. The names of local variables are erased and replaced by stack frame offsets when it compiles the source code to IL. Namespace and type names are still present in the assembly. The JIT compiler erases those, replacing them with code offsets for methods and data offsets for fields. The length of the identifier names doesn't matter here, the lookup only happens once.

Eliminating the expense of the name lookup in an interpreter isn't hard btw. A decent interpreter tokenizes the source code, essentially a pre-compile step to make the interpreter more efficient. Such an interpreter would not have a slowdown issue with long identifier names either.

No, once compiled the original variable names are no longer used. Size of variable names should have a very small affect on compilation time, but not on execution time.

Interpreted languages are affected a little bit by long variable names. Long names are more to read, store and lookup each time they run, but the affect should be very small. Latency in reading/writing to a disk or even the screen should far exceed the delay caused by longer variable names.

If execution time is the problem, then more execution efficient algorithms will almost certainly provide much greater returns than shortening variable names. If memory pressure is the problem, memory efficient algorithms will again likely save much more than shortening variable names. If the solution is algorithmically as tight as it can be, it is time for a new language.

There are few absolutes in programming, but I feel confident in saying shortening variable names in source code for performance reasons is ABSOLUTELY the wrong decision EVERY time.

No, I don't think that long variable have any impact on the execution performance of a .NET application. AFAIK, intermediate code (in MSIL) in a .NET assembly is translated to machine language before it gets executed. This would be where variable names are definitely "thrown out" (if it hasn't already happened earlier) and replaced by simple memory addresses.

It doesn't matter. Eventhough you Can get the names when decompiling (see other posts for details) those names are not used by the IL instruction Reading from or writing to variables/fields. The variables and fields are identified through a different construct. In the reflection.emit namespace these are represented by LocalBuilder (for a local variable or FieldBuild for fields) and to further stress the point: they don't even need to be explicitly named.

I think the question about name length is actual only for Script# projects (in case of translating of C# to JavaScript).