5 replies to this topic

[TheouAegis]

Yes, this is just a nit-pick question, because even if my theory is right, it would only shave off a couple kilobytes from the file size and in this day and age that's negligible.

With the variable_local_ and variable_global_ family of functions, the variable name is passed as a string, which of course is simply a series of bytes with each byte representing a letter. The fact that these functions even exist to be included in the executable suggests variable names themselves are actually stored in the executable.

Unfortunately, one does not simply view the executable in a hex editor. I tried this and noticed there were a lot of legible words, many of them looked like C (or C+ or whatever) commands and Windows-related commands. I'm not sure if this is wasted space or if the executable really does need all those lines, but it told me it stored some variables by name (even if they were system). I tried an ASCII search for a known variable name and a search for the name with a space between each letter, but that didn't work. That doesn't mean the words aren't in the data, it just means I probably wasn't searching correctly.

Now, I don't know how GM's compiler works, but I tested if changing the length of a variable's name altered the size of the executable. First off, GM does some funky stuff with the file name -- the executable with a 2 added at the end of the file name resulted in a smaller file size than the one with just the original file name (I tested this, don't know why it does it). So after changing the name of executable with the normal file name via Windows' "rename" function so it wouldn't mess with the file size, I recompiled the executable and compared the file sizes. All I can say is I don't know how GM compiles, because the executable with the longer variable name was smaller than the executable with the shorter variable name. Everything else was the same.

But that doesn't change the issue: ultimately does GM store variable names in the executable (encrypted or truncated or something) and if so, would it be better to use shorter variable names? This is all "in theory", because in practice this would be a pain in the ass to actually do and would probably get confusing very quickly.


And if someone can tell me why my executables have different file sizes even when they're the exact same except for one letter, I would appreciate that too.

Edited by TheouAegis, 29 July 2012 - 04:57 PM.

[jo-thijs]

you seem to be right.
and even funnier, if you refer to the variable with [0] after it, it is even smaller, though it does the same!

[Gamer3D]

The interpreted versions of GM do store variable names. Easy way to check this: see if you can access variables by name at run-time (The variable_local/global_get/set functions, execute_string, etc. Compile-time name access doesn't count)

GM works by copying code into a pre-made executable (To try to hide this, it's encrypted. Of course, "decompilers" are conceptually simple once you find the decryption key).

In theory, at some point GM will use a compiler. Then the variable names will no longer be in the executable, and the executables should be far faster. Of course, it's always possible to mess this up somehow, but that's unlikely.

[DanRedux]

If you make a small game, the filesize will be small anyway, and because it's a small game you could only save a couple bytes.
If you make a large game, the filesize will be huge anyway, and because it's a huge game you could save a lot more bytes but with much less of a reduction in filesize percentage-wise. .5kb on a 15mb file doesn't really matter.

So while it's good that you're thinking deeper into things, variable length doesn't matter. Always, in every language, go for variable names that are concise and descriptive. Looking back on the work a year later and knowing what the variables all mean and do is more important than saving a few bytes. However, yes, you would be saving that space if you did use smaller names.

[torigara]

And if someone can tell me why my executables have different file sizes even when they're the exact same except for one letter, I would appreciate that too.

One thing to consider is that GM executable files will be encrypted and/or compressed. For these algorithms, the output length isn't necessarily the function of input length but also affected by the actual contents of the data. (For instance, many compression algorithms use variable-length bits like Huffman coding to reduce the size.)

As the consequence, 100 bytes of data will be compressed into 50 bytes, 63 bytes or sometimes 42 bytes depending on its contents. Similarly, 99 bytes of data can be compressed int 49 bytes, 65 bytes or 40 bytes. So, you will sometimes see that the output file suddenly grows or reduces by a dozen of bytes when you only add or change 1 byte to the input. That's just a coincidence.

If the file is encrypted, the output size may also be affected by the encryption key. Chances are, Game Maker chooses different key or embed the time stamp each time it generates an executable file, ending up in different output size.

[2DLuis]

GM works by copying code into a pre-made executable (To try to hide this, it's encrypted. Of course, "decompilers" are conceptually simple once you find the decryption key).

Just to slightly modify that, the GM editor produces somewhat of a bytecode which is appended onto its runner exe .