Does variable name length matter for performance C#?

Question

I've been wondering if using long descriptive variable names in WinForms C# matters for performance? 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#?

Agape

Answer 1

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.

Hazelhazelnut

That's weird because when i look at my source .exe with reflector it shows variable names that are the ones I've used. – Agape

True, but doesn't the intermediate language code in a .NET assembly get translated to machine language before it's executed? (Also see my answer.) If so, it doesn't matter whether variable names are still in the assembly, because what you see there is not what will get executed. – Vanzant

Compiler also creates .pdb files that actually store variable names and code. But this files are used only for debugging, not running of the .NET applications. Maybe Reflector can read this files too. – Hazelhazelnut

Reflector gets symbol names from .pdb if it exists and this behavior is enabled in Reflector settings. – Topaz

Then i would expect performance hit on application start when variables are read and put into memory (when assembly gets translated to machine code) – Agape

@MadBoy: I think it gets that info out of the PDB. – Birdseed

It's possible it starts more slowly because of the long names (larger file). Changing every name to 1 letter will save you 1ns of every application startup. It's definitely a good way to optimize the startup time. </sarcasm> – Threat

@MadBoy: there would be no perfomance hit because there are no variable names stored in MSIL, so JIT does not care about it. – Hazelhazelnut

@Threat you miss opening <sarcasm> :p – Agape

@Topaz I've deleted PDB files and it still sees names (after restart). – Agape

I was even able to open a class library (not mine, without source and of course without PDB) in Reflector and still see original variable names... – Blastoff

@mnn: I don't know how you did it. I've just created sample project, compiled it and opened by Reflector - variable names were there. Then I closed reflector and deleted pdb file. After I opened the reflector it used generated veriable names, not mine. – Hazelhazelnut

@mnn: how can you be sure that the names are original if you didn't see the source? – Topaz

Local variable names are erased. Member variable names are preserved. – Bucephalus

It is just different naming. Member variables are usually called fields, not variables :) – Hazelhazelnut

Reflection will not work if compiler didn't keep the variable / function / class names in assemblies. In unmanaged code, it doesn't know the variable names. – Ashelman

Answer 2

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.

Huntingdon

Answer 3

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.

Terpineol

Dim UnlessYouOftenUseVariableNamesThatAreSoLongThatTheyMayBeConsideredANovellaAllOnTheirOwn ;) – Terpineol

Answer 4

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.

Vanzant

What about start time of such application? Would it be shorter? – Agape

Variable names do not get to MSIL. – Hazelhazelnut

My question is very theoretical. I don't do that much performance stuff to be bored with even 1second here and there. – Agape

Answer 5

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.

Demimondaine

Answer 6

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

Baronage