AutoHotkey Community

[Chris]

Currently, both AutoHotkey.exe and compiled scripts are compiled in C++ to favor performance over EXE size. This increases the size of each EXE by about 15 KB (and this increase will get larger over time as more code is added).

The performance loss of not doing this would probably not be noticable in a typical script. However, the loss might be more significant for CPU intensive scripts (math loops, etc).

Note: If compiled scripts are optimized for small size but AutoHotkey.exe is kept optimzed for performance, there is a miniscule chance that scripts that rely on precise timing will behave differently in compiled form due to their slightly lower performance. This might be another reason to leave things as they are.

On a related note, I've recently been thinking of other ways to reduce the size of compiled scripts. One way is to offer an optional scaled down feature-set that omits syntax checking (5 KB), keyboard/mouse hooks (40 KB?), and maybe the GUI feature (15 KB?) However, I have some doubt that these small savings are worth the confusion of an extra compiler option, not to mention the extra effort to maintain two different AutoHotkeySC.bin files.

Ideally, scripts should be compiled to include code only for the commands they actually use. However, this seems too difficult and impractical to be worth it.

Comments are welcome.

[Titan]

[Nemroth]

For my point of view, there is no such difference of size between a large and a short compiled script (it seem there is a common minimum size), and they are usually (for me) small in size. So I prefer to gain in performance rather than in size.

[deguix]

For me, using this language (AutoHotkey) the performance matters in most of the aspects of a script, like hotkeys... And that's the main reason I'm here.
_________________
Working now on:
NSIS Wiki (NSIS)

[jonny]

15kb isn't much to worry about. A slight decrease in performance that affects regularly used scripts, that is. I don't care much about the size of my scripts (compiled or not), but the performance can sometimes make a big difference.

[Chris]

[sleepyy35]

If I understand this rite we loose some performance and the exe size will go down
I personally like the small compile size of my scripts but i think performance is more important
_________________
^sleepy^

[Rajat]

i'd have voted for size had the cut been bigger... like bringing the size down to nearly 100 or lesser.
_________________

[Guest]

[Chris]

[JSLover]

Ok, now I have a new idea...I'm going to have to just explain it & ask anyone if they think it'll work...

In a PE exe file, each "thing" AHK does is a function...so say you have...

[Rajat]

now that's some fab thinking JSLover!
_________________

[Chris]

[[deXter]]

A slightly old topic, but I feel that smaller compiled exe's should be more of a priority now. AHK keeps getting better and better, but unfortunately, the filesize just keeps on growing..

I dont know why this discussion has been unnecessarily complicated. It would be quite simple to implement this actually.
Instead of thinking along the lines of performance v/s size, how about a modular approach?
What I propose is to abandon the current AutoIT based exe compiler system entirely, which is where I suppose the limitations lie.

Instead of having one big AutoHotkey.exe, you could have several smaller files (exes/dlls). There could be a small Ahk-main.exe (or something) which would include the core AHK features like hotkeys/hotstrings. You could then group up various features in several dlls/exes. For eg, all the GUI stuff in one dll, image/screen stuff in another and so on. The main exe parses the script as normal, and it simply would call the necessary dll/exe as and when required.

Similarly, the script compiler would parse the script and include only those dlls/exes that would actually be required according to the functions used.

And as for the compilation itself- the main exe, the dlls and the script itself can be simply bundled into a single file. There would be no need to use the AutoIt compiler.
For starters, there are many exe-bundlers out there which can do that (for eg, PEBundle). And a final coating of UPX to top it up.

Thus the changes would all have to be made at the source level itself (which is much simpler), rather than modifying binaries. And I suppose it wouldn't be that difficult either as the code is already present. What you would be needing to work on is the grouping and seperation and of the source files.


If all this is done sucessfully, we could be looking at compiled scripts as small as 50k! (or smaller!)

[Chris]