Does the length of variable effect the size of output exe?

Started by ragdogz, January 31, 2009, 12:47:16 PM

Previous topic - Next topic

ragdogz

1st code like this:

.data
MessageSuccessOpenFile001  db "OK, You have opened the file 1 successfully...",0
MessageSuccessOpenFile002  db "OK, You have opened the file 2 successfully...",0
...
...
...
MessageSuccessOpenFile100  db "OK, You have opened the file 100 successfully...",0


2nd code like this:

.data
MsgSuc1  db "File 1 open!",0
MsgSuc2  db "File 2 open!",0
...
...
...
MsgSuc100  db "File 100 open!",0


does the 2nd code produce the smallest exe file than 1st code? my behaviour in writing a variable is using a long name so i can easily determine what it is for.. i ask this regarding this topic: http://www.masm32.com/board/index.php?topic=7290.0

Quote from: Tedd on May 13, 2007, 01:15:38 PM
Why not say "Hi" instead of the byte-wasting "Hello" :bdg


Tedd

Haha. That was a joke, in context :P

Anyway, if you use longer strings then it's going to require more bytes to store, and so the resulting exe is going to most likely end up bigger. If there's only a difference of a few bytes, then it's unlikely to make any difference as PE sections are padded anyway (unless you happen to go slightly over the padding size, and then you get a whole new section of padding.)
In general advice, I would say don't even worry about it, unless it's specifically your aim to create the smallest most cryptic exe you can. Otherwise, make your program as nice and simple to use as you're able - that's the main difference between good and bad software.

As for this particular instance, you're repeating almost the exact same string over and over, so it would be a lot better (and space saving!) to use a template string with wsprintf, or write the value inline yourself -- e.g. "OK, You have opened the file %d successfully..." or "File %d open!" (whichever you prefer - the size difference is minimal, for only one occurrence.)
No snowflake in an avalanche feels responsible.

jj2007

The length of the variable name has no influence on code size, except if you export the names in the context of a library. The sample below generates 1000 variables. Linked with polink and option /merge:.text=.data, this assembles at 1024 bytes.


include \masm32\include\masm32rt.inc

NameCt = 0

NextVar MACRO
  NameCt = NameCt +1
  tmp$ CATSTR <MyVar>, %NameCt, < dd ?>
  % echo tmp$
  tmp$
ENDM

.data?
REPEAT 1000
NextVar
ENDM

.code
start:
mov MyVar1000, 123 ; just to verify that this variable exists
invoke MessageBox, 0, chr$("Masm32 is cute"), chr$("Hello"), MB_OK

exit ; short form of invoke ExitProcess, 0

end start


ragdogz

@Tedd
yes, because of reading your joke in that topic, then suddenly i realized i have so many long and repetition strings in my code.. wow! this will be a space consuming..
and u will be more amazing if u see my whole code since many other repetition syntax which actually can be shortened  :green
you know, almost all newbies code like that.. :green

thanks for your explanation and advice..

@jj2007
"The length of the variable name has no influence on code size"

code size? what do you mean by code size? the asm source code file?
i'm talking about the final output exe file..
i'm sorry if i don't get what you mean.. :red

"except if you export the names in the context of a library"

and what does it mean? i only export my code to the final exe file, like this:

ml /c /coff /Cp test.asm
link /SUBSYSTEM:WINDOWS /LIBPATH:\masm32\lib test.obj test.res


so it means using 100 variables named MessageSuccessOpenFile001 or MsgSuc1 will make no different in size of the output exe file?
then i prefer MessageSuccessOpenFile001 to MsgSuc1 and shortened the containing strings like Tedd said..

donkey

Quote from: Tedd on January 31, 2009, 04:58:13 PM
Anyway, if you use longer strings then it's going to require more bytes to store, and so the resulting exe is going to most likely end up bigger.

The "variable" name is just a label for use by the assembler/compiler, it is not stored in the executable except on debug builds and has absolutely no effect at all on the size of final builds, they all resolve down to an address (DWORD in 32 bit asm) regardless of how many characters they have in your source.
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

jj2007

Quote from: busclock on January 31, 2009, 05:41:27 PM
@jj2007
"The length of the variable name has no influence on code size"

code size? what do you mean by code size? the asm source code file?
i'm talking about the final output exe file..
Me too :bg

Quote
so it means using 100 variables named MessageSuccessOpenFile001 or MsgSuc1 will make no different in size of the output exe file?

Exactly. The names just tell the assembler where to point the mov MyVar, eax code. It makes a 4-byte difference if MyVar dd is in the .data? or .data section. Variables in data? do not increase the .exe size at all, but they are zero initially, i.e. you cannot give them a value different from zero. Since I put the 1000 variables in .data?, the code size remains at its absolute minimum, 1024 bytes.

ragdogz

oww now i have a clearer view about this..
thank you all..  :U

BlackVortex

No, thank YOU for this awesome thread    :cheekygreen:

Tedd

Thank you for that clarification Donkey, I never knew :P (I did say 'strings,' not 'variable names.')

Anyway, yeah, to repeat the point: variable names don't affect the size of the exe (unless you include debug information, but then size shouldn't be your problem) - it's the actual contents of the string that matters.


(The mix of replies comes from changing both the length of the strings and their variable names together in the examples.)
No snowflake in an avalanche feels responsible.