Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Length of Variable Names Affect Compiled Executable?

Reply
Thread Tools

Length of Variable Names Affect Compiled Executable?

 
 
John
Guest
Posts: n/a
 
      09-26-2006
Does the length of my C variable names have any affect, performance-wise, on
my final executable program? I mean, once compiled, etc., is there any
difference between these two:
number = 3;
n = 3;

I know its setting aside storage for the variable itself; does it also use
up more storage if the variable name is longer? I realize it would probably
take quite a lot of long variable names to make any impact if so, but I was
just curious if anyone knew...


 
Reply With Quote
 
 
 
 
Thad Smith
Guest
Posts: n/a
 
      09-27-2006
John wrote:
> Does the length of my C variable names have any affect, performance-wise, on
> my final executable program? I mean, once compiled, etc., is there any
> difference between these two:
> number = 3;
> n = 3;


The Standard doesn't say.

Normally compiled code will be the same. It is conceivable for a C
intepreter to take longer.


--
Thad
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      09-27-2006
In article <4519c0e6$0$33784$(E-Mail Removed) s.com>,
Thad Smith <(E-Mail Removed)> wrote:
>John wrote:
>> Does the length of my C variable names have any affect, performance-wise, on
>> my final executable program? I mean, once compiled, etc., is there any
>> difference between these two:
>> number = 3;
>> n = 3;


>The Standard doesn't say.


>Normally compiled code will be the same. It is conceivable for a C
>intepreter to take longer.


-potentially- there might be debug information in the executable
that records the original variable names; a larger variable name might
result in a larger debug section; depending on the OS details,
that -might- result in a slightly larger initiation time (e.g. because
a larger file is being parsed apart to link and load.) But likely
any such effect would be trivial compared to the other factors affecting
executable file size, such as the amount of code, or the optimization
level.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
 
Reply With Quote
 
iliwoy5@sina.com
Guest
Posts: n/a
 
      09-27-2006

John wrote:
> Does the length of my C variable names have any affect, performance-wise, on
> my final executable program? I mean, once compiled, etc., is there any
> difference between these two:
> number = 3;
> n = 3;
>
> I know its setting aside storage for the variable itself; does it also use
> up more storage if the variable name is longer? I realize it would probably
> take quite a lot of long variable names to make any impact if so, but I was
> just curious if anyone knew...


If we compare variable names in C with in assemble language,we can see
as follows:
In C:
int number = 3;
int n;
n=number;

In asm: (ebp point to the top of stack before going into the
procedure.)
mov dword ptr [ebp-4],3
mov eax,dword ptr [ebp-4]
mov dword ptr [ebp-8],eax

The C compiler hold a table to storage the variable names,but after
compiled to assemble language,the table will be distroyed.

In a same question:
We can write in assemble language like this:
In asm:
..data
number dw 3
n dw ?
....
..code
....
mov ax,number
mov n,ax
....
the same question is :is there any difference between these two
variable names?
After it complied to opcode,it may be executed like this:
....
A10000 ( mov ax,[0000])
A30200 ( mov [0002],ax)
....

So,the table holded by assemble compiler will be destroyed after it
compiled to opcode.

 
Reply With Quote
 
jmcgill
Guest
Posts: n/a
 
      09-27-2006
John wrote:

> I know its setting aside storage for the variable itself; does it also use
> up more storage if the variable name is longer?


No. On some compilers, if you compile with a "debugging symbols" switch
enabled, a symbol table of some sort will be generated which will make
the code larger, but it would be a rather broken implementation that led
to a performance cost as a result.

 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      09-27-2006
>Does the length of my C variable names have any affect, performance-wise, on
>my final executable program? I mean, once compiled, etc., is there any
>difference between these two:
>number = 3;
>n = 3;


By posting your article, you've probably used up much more CPU time than
your program will ever use during its lifetime. So stop worrying about
its performance.

The C standard does not require a program to have any kind of
performance: good, bad, sucky, awful, better than, or worse than.

>I know its setting aside storage for the variable itself; does it also use
>up more storage if the variable name is longer? I realize it would probably
>take quite a lot of long variable names to make any impact if so, but I was
>just curious if anyone knew...


A program compiled with debugging symbols will probably take up
more *DISK* storage depending on symbol length. These symbols may
or may not ever get into memory when the program is run.

It is possible, especially if you have a habit of using terabyte-long
symbol names, that name length could affect the runtime of the
dynamic linker that might be used on program startup.

 
Reply With Quote
 
=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=
Guest
Posts: n/a
 
      09-27-2006
Walter Roberson wrote:
> In article <4519c0e6$0$33784$(E-Mail Removed) s.com>,
> Thad Smith <(E-Mail Removed)> wrote:
>> John wrote:
>>> Does the length of my C variable names have any affect, performance-wise, on
>>> my final executable program? I mean, once compiled, etc., is there any
>>> difference between these two:
>>> number = 3;
>>> n = 3;

>
>> The Standard doesn't say.

>
>> Normally compiled code will be the same. It is conceivable for a C
>> intepreter to take longer.

>
> -potentially- there might be debug information in the executable
> that records the original variable names; a larger variable name might
> result in a larger debug section; depending on the OS details,
> that -might- result in a slightly larger initiation time (e.g. because
> a larger file is being parsed apart to link and load.) But likely
> any such effect would be trivial compared to the other factors affecting
> executable file size, such as the amount of code, or the optimization
> level.

Typically though, that debug information is not loaded by other
than special tools - such as a debugger.

Then again, this implementation specific.
 
Reply With Quote
 
Ark
Guest
Posts: n/a
 
      09-27-2006
John wrote:
> Does the length of my C variable names have any affect, performance-wise, on
> my final executable program? I mean, once compiled, etc., is there any
> difference between these two:
> number = 3;
> n = 3;
>
> I know its setting aside storage for the variable itself; does it also use
> up more storage if the variable name is longer? I realize it would probably
> take quite a lot of long variable names to make any impact if so, but I was
> just curious if anyone knew...
>
>


An often overlooked case is when by using the stringize operator you
introduce names (or similar) to the code. E.g.
#define FYI(x) printf("FYI: %s = %d\n", #x, x)
................
FYI(n);
FYI(number_of_characters_grows);

A typical case of something similar is the assert macro (which people
sometimes leave active in the release code by #undef'ing NDEBUG by hand).

In these cases the length of a name matters - but all things considered,
not terribly much.

--
Ark
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      09-27-2006
John said:

> Does the length of my C variable names have any affect, performance-wise,
> on
> my final executable program? I mean, once compiled, etc., is there any
> difference between these two:
> number = 3;
> n = 3;
>
> I know its setting aside storage for the variable itself; does it also use
> up more storage if the variable name is longer? I realize it would
> probably take quite a lot of long variable names to make any impact if so,
> but I was just curious if anyone knew...


I have read the parallel replies with great interest and amusement. It's
amazing how much juice you can squeeze from C.

Nevertheless, *in general* the answer to your question is "no". Yes, various
people have drawn attention to various exceptions to that answer, which you
may wish to take into account. But in the general case, your implementation
will (or can be told to) discard all such information.

Thus, using b instead of CurrentBalance is an unnecessary "optimisation"
which will, in the general case, have no impact on performance. Write
clear, readable code using good algorithms and descriptive identifiers.
Worry about performance only in the extremely rare cases where good
algorithms don't deliver sufficient performance to meet your users' needs.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      09-27-2006
In article <451a10a7$(E-Mail Removed)>,
=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?= <(E-Mail Removed)> wrote:
>Walter Roberson wrote:


>> -potentially- there might be debug information in the executable
>> that records the original variable names; a larger variable name might
>> result in a larger debug section; depending on the OS details,
>> that -might- result in a slightly larger initiation time (e.g. because
>> a larger file is being parsed apart to link and load.)


>Typically though, that debug information is not loaded by other
>than special tools - such as a debugger.


>Then again, this implementation specific.


Sure, typically not loaded, but unless the implementation's standards
for the format of executables is such that the debug information must
be the -last- thing in the executable, then the code that loads
the executable into working memory must read the debug information
to get past it to the other important information.

The loader might fseek() around the debug information and thus not
actually read it in, but fseek() can interfere with automatic OS
pre-read of files so fseek() is not -always- faster than just reading
the characters and throwing them away. Interestingly, using lots
of large variable names can, by increasing the debug section size,
drive the debug section size closer to the point where fseek() is
worthwhile
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
checking for mis-spelled variable names / function names News123 Python 2 11-26-2008 12:37 AM
If I create a page, then it's compiled upon first request, where cani find the compiled code?? lander ASP .Net 5 03-05-2008 04:34 PM
confusion between global names and instantiated object variable names wanwan Python 3 10-14-2005 09:46 PM
g++ compiled C++ code called from gcc compiled C code Klaus Schneider C++ 1 12-02-2004 01:44 PM
Does amount of code compiled for a page affect server performace? CB ASP General 1 02-23-2004 09:29 AM



Advertisments