autoit 3.3.10.0 is HUGE

[legend]

I think it's very wrong to include this: '?do=embed' frameborder='0' data-embedContent>>

in autoit3.exe, now a simple msgbox, is more than 850 kb. that's pretty damn large, for a simple msgbox.

[guinness]

I think it's very wrong to include this: '?do=embed' frameborder='0' data-embedContent>>

in autoit3.exe, now a simple msgbox, is more than 850 kb. that's pretty damn large, for a simple msgbox.

Well if you're including WinAPIEx for a MsgBox() then you need to read the help file again. Anyway your complaint is without merit, as you can use Obfusctator to /StripOnly the source code.

There is just no pleasing some people. Sheesh!

Edited December 23, 2013 by guinness

[legend]

http://www.autoitscript.com/autoit3/docs/history.htm

UDFs:

• Added #1158: WinAPIEx integrated, split under WinAPI*.au3.

I believe that's why the default autoit3.exe is that big.

[guinness]

legend, that's what we call an include file aka UDF, it's in no way in-built into the AutoIt3.exe executable. Seriously, what is the issue with file size when we live in a world where data storage is cheap and Internet connections are faster than the old 56k modems.

Have you not been around when Jon, Valik and trancexx were uploading beta releases? If you're not happy with the bug fixes and new features, then stick to v3.3.8.1 and leave this for the rest of us who enjoy coding.

Edited December 23, 2013 by guinness

[UEZ]

By default UPX is not enabled anymore and thus the executable size is larger than compressed.

800kb for an exe is that much?

Br,

UEZ

Edited December 23, 2013 by UEZ

[legend]

I'm aware of that, but it's still way bigger than earlier release last one was 650 kb, while the new is about 860 kb.

not a big problem, but it just gets bigger and bigger.. 

[UEZ]

Using this code give me 337kb exe.

#AutoIt3Wrapper_UseUpx=y
#AutoIt3Wrapper_UPX_Parameters=--best --lzma

MsgBox(0, "Test", "Test")

Still larger than the previous versions but AutoIt has more included features now.

Br,

UEZ

Edited December 23, 2013 by UEZ

[JLogan3o13]

I'm aware of that, but it's still way bigger than earlier release last one was 650 kb, while the new is about 860 kb.

not a big problem, but it just gets bigger and bigger.. 

 

210kb difference and you felt the need to post a topic claiming it's HUGE, seriously?! If wasting forum members' time on the inconsequential was your goal, congrats.

Edited December 24, 2013 by JLogan3o13

[jchd]

I also carry something that gets bigger and bigger and no woman complains about it (yet).

My age.

Seriously, Win 7 is significantly bigger than Win 3.11 as well.

[kylomas]

jchd - Thank you sir!  You just made my night

[UEZ]

I also carry something that gets bigger and bigger and no woman complains about it (yet).

My age.

 

What a pity and we cannot UPX it (yet).

Br,

UEZ

[Jos]

210kb difference and you felt the need to post a topic claiming it's HUGE, seriously?! If wasting forum members' time on the inconsequential was your goal, congrats.

Where are the days we wanted to keep it below 100Kb .. must be getting old

To put this in perspective: The first PC I worked with that even had a harddisk was 10Mb (1984) and I just ordered a NAS with 8Tb... guess that is what is called progression.

Jos 

Edited December 24, 2013 by Jos

[Somerset]

Where are the days we wanted to keep it below 100Kb .. must be getting old

To put this in perspective: The first PC I worked with that even had a harddisk was 10Mb (1984) and I just ordered a NAS with 8Tb... guess that is what is called progression.

Jos 

*snickers*

[JCE]

If you take something and wrap it up, it becomes bigger. Do it again it becomes even bigger.

If you want the smallest possible executing  programs you'll need to learn to write in binary which no one does.

If you want number 2 on the list you will have to go with assembly. 

C for number 3.

Everything you can do with autoit can be done with c and assembly. When space is limited like on device driver and cell phones you need to worry more about optimization. After you learn c or assembly you will have the smallest and fastest code out there... Well that's if you have mastered writing small optimized code.

And if you want to argue over whats better speed or size i'd have to say neither. I'd go with functional code first. Does it get the job done?

I wouldn't worry about size. I think autoits aim is more of having something hobbyist can grasp and comprehend. 

If it doesnt meet your requirements, then use something that will. If they isnt anything that does then you will need to create it.

 

Edit. 

Btw count how many Msgbox your computer can store and tell me how huge it still sounds...

I got a small flashdrive beside me here that would hold 50,000 programs that size.

Edited December 24, 2013 by JCE

[Ascend4nt]

I think size is always a relevant discussion.  Anyone that says size of executables are unimportant this day and age is being a bit ignorant about the current trend towards mobile devices, where 'app' size is a pretty important issue. Additionally, data locality (cache optimization) and multi-core optimization are becoming important even in advanced server architectures..

Of course, since AutoIt is an interpreter that doesn't even compile to bytecode, performance will never be anything but sloww.. and on the issue of size, well, PCs running Windows have plentiful amounts of storage these days, this is true..

Then again, if you start piling alot of executables together, you can run your storage space down quickly.  Plus its pretty important for those of us running portable applications to have smaller executables to load, since flash drives are still pretty slow.  If you take a look at the winPenPack site, you'd see that the launchers are sometimes actually bigger than or comparable to some of the actual programs they are portablizing... plus its that much more time to load their launcher.  This could somewhat be reduced by having a common AutoIt executable and using something like A3X files, though

Anyway, its nice to see AutoIt's feature-set grow, thats important moving forward.  I still believe there's a few tweaks that could possibly be made to reduce the final executable size.. perhaps compiling on VC2010 vs. VC2012/2013, or maybe removing any references to IOStreams, for example.  (I couldn't say for sure as its closed-source)

Still, older versions are available to use to compile executables - so long as newer features (or bugfixes) aren't needed.  And then there's A3X..  so, with a little extra effort, file size can be shrunk considerably.

Or just go with a different language. A simple MsgBox program can compile to under 4K with C.

[jpm]

I can understand that smaller AutoIt3.exe can make the compile smaller but the solution is really to use .a3x.

Remember you can execute them with an compiled .exe so you don't even need to distribute the autoIt3.exe file

Just one compiled file and .a3x ones.

Cheers

Jpm

[Jon]

I think size is always a relevant discussion.  Anyone that says size of executables are unimportant this day and age is being a bit ignorant about the current trend towards mobile devices, where 'app' size is a pretty important issue. Additionally, data locality (cache optimization) and multi-core optimization are becoming important even in advanced server architectures..

I agree. I'm always wary of exe bloat and try and keep it to a minimum. I used to have a rule that the AutoIt.exe couldn't be more than 100KB compressed.   But features add size in the current architecture and that's why I resist features when a UDF is acceptable. It's always a balance - not one that I always get right either. 

 

This could somewhat be reduced by having a common AutoIt executable and using something like A3X files, though

Yeah, that was the whole point of .a3x along with a super-permissive license for redistributing autoit3.exe. If I were distributing lots of files it's how I would do it. I don't have the skill or the time to create a proper compiler so that's all I've got.

 

Anyway, its nice to see AutoIt's feature-set grow, thats important moving forward.  I still believe there's a few tweaks that could possibly be made to reduce the final executable size.. perhaps compiling on VC2010 vs. VC2012/2013, or maybe removing any references to IOStreams, for example.  (I couldn't say for sure as its closed-source)

It's always been compiled with every file shrinking option that can be done. We don't have any exceptions/c++ stream features enabled - and we don't use any of the STL classes.

The initial compile is done in "minimize size" mode which gives:

850KB (Visual Studio 2012)

820KB (2010)

One of the biggest increases in size this release was because we had too many bugs in the math functions (we were using bespoke assembly code for all these functions since 2003) and we finally had to use the VC runtime ones to fix things - this instantly added 60KB, ouch, but at least it's fixed and other future math functions won't mess up or add more size.

Even compiled without the VC runtime in static mode it is 666KB - so still in the "people will moan" territory and not worth the hassle of making everyone install the VC runtimes.

You'll notice that the current release exe is actually 70KB bigger than I mention above. That's because we then run it through a few common operations and use the Visual Studio tools to analyse performance and then recompile the hotspot functions for speed. The resulting file sizes between the different compilers vary wildly at this point and generally the latest compiler tends to perform better. VC 2010 in this mode gives a much much bigger exe than 2012 and it's about the same speed (a touch faster). This 70KB vs the speed boost is another aspect to weigh up - the perf boost significant enough that I choose to use it.

We also add a far bit of bloat when we reduce bugs. We tend to use a lot of string classes and smart pointers in new code and this is totally worth it to reduce those impossible to find bugs that haunt AutoIt for years. Many of the bugs fixed this release were due to some buffer overrun or buffer miscalculation, especially when different people are touching the same source. When old functions are revisited they tend to get the same treatment. Totally worth it IMO.

Supporting older OSes also adds some KBs - not much but 10's of KBs. We have to check for, and dynamically load functions, and perform cleanup afterwards. We have wrapper functions that allow this to be done in an easy way but they are all C++ classes that add a little size because they perform various checks and auto-clean up in as hassle free (and bug free) manner possible. In general I try to stick with an OS level that is under MS support which usually (not always) corresponds to the latest compiler level. At the moment we are going one step beyond that in supporting XP RTM and adding some ugly compiler hacks to allow this. 3.3.12.0 will be changed to XP SP3 which will remove another set of these dynamic functions.

I rambled on a bit there, but thought some of the internals might be of interest.

Edited December 27, 2013 by Jon
Typos.

[trancexx]

The main reason why ability to #include a3x-es was added was to move number of built-in functions from compiled binaries (raw .bin interpreters used by the compiler) into precompiled private au3 files. The idea was to extend and use pragmatic directives to "include" needed precompiled files/functions.
To me it never made sense why compiled executable should include all built-in functions even though they were never used by user's code. Considering AutoIt is dllcall capable and also since some time works with all kind of objects either late or early bound, all preconditions for the idea were made.
Really large number of functions can be taken out of the binary stub with no performance hits. Functions like Beep, Mouse..., Reg..., Tcp, Udp, and tens of others which aren't any faster because of being part of the binary code.
Of course that some functions can't be taken out, for example Adlibs or some that do lots of calculation like Pixel-whatever but large number of others are very good candidates.

Anyway, the idea was to do something like this:

#pragma use(socket)

TCPStartup()
;...

...and in case of au3 script which is run by AutoIt.exe TCP functions would be built-in (even not necessary) and in case of compiled executable Aut2Exe would add needed a3x code with functions written for it in simple easily maintainable AutoIt code.

This way the size of compiled executables would really depend just on set used functions plus absolute minimum interpreter needs and wouldn't have burden of unnecessary code.

Pragma directive would be mandatory for code that uses Execute or some other run-string function, but for "normal" code it can even be dropped out because compiler can detect used functions itself.

[Ascend4nt]

John, thanks for the nice explanation on exe size.  Its nice to see that you are using smart pointers and string classes, as I recall the old public source code was very much C++-lite (meaning it was mostly C style code with some dangerous buffer size assumptions and minimal use of anything object-oriented).

trancexx, nice to hear from you as well. A more modular approach to compilation would be nice, but I imagine the effort to do such a thing would require a lot of time and effort and a bit of rethinking.  Probably not worth it in the long run, unless AutoIt became open-source and more people could contribute.

[trancexx]

trancexx, nice to hear from you as well. A more modular approach to compilation would be nice, but I imagine the effort to do such a thing would require a lot of time and effort and a bit of rethinking.  Probably not worth it in the long run, unless AutoIt became open-source and more people could contribute.

Ah but it's as simple as it gets. A matter of rearranging. Effort or time needed for that is minimal compared to time thas's been lost on almost irrelevant things in the past.

But don't take my word for it.