2014R3 vs 2014R2.1 Win32 File Size / ICU DLLs

As has been discussed before, the Windows EXE app size took a 24MB jump in size: https://forum.xojo.com/17246-hello-world-app-size

In my special snowflake use case, this more than triples my compiled app size, and is a problem. I’m trying to decide what to do.

It appears that 2014R3 really has a ton of Cocoa/Yosemite fixes, so I’d rather use it for my Cocoa builds.

But I don’t see very many Windows-related fixes in the 2014R3 release notes, so I’m considering building my Windows app using 2014R2.1. Having to switch between IDE versions will be a pain, no doubt.

Anyone facing a similar decision?

24mb isn’t that much nowadays. Don’t think any of your users will complain about this.

Please assume for the sake of this discussion that I have a special case, and the size does matter. The question is : what to do about it?

Well, in that case you answered your own question :slight_smile:

The new Text class and the ICU dependencies are where all of the excess size is coming from. It’s pity there isn’t a flag that says “Ignore multi-language support” or “Use only deprecated String class” for the build settings because you get all of that ICU stuff even if you’re not using it.

For now 14r2.1 or earlier is the only solution.

Keep in mind that ICU also gets you the new locale specific date and number parsing capabilities connected with the new Text data type.

[quote=150473:@Tim Jones]The new Text class and the ICU dependencies are where all of the excess size is coming from. It’s pity there isn’t a flag that says “Ignore multi-language support” or “Use only deprecated String class” for the build settings because you get all of that ICU stuff even if you’re not using it.
[/quote]
You’d need to be able to strip the framework itself which isn’t likely to happen

Thanks for the ideas : I did try the obvious test : make an app which doesn’t use the Text class, and then delete the icut53 DLL file, but the app won’t launch then.

That wont work.
The only viable option is to use an old version.

Could you do something like use a compressed file system? Or a ram drive or similar?

Same issue on Linux. Also consol.
Please consider add a build option where we can do it the old way.

I use Xojo in small embedded Linux devices with very little ram availible.

We’d have to have a means to strip out the Text data type from the language - unlikely to happen

It is possible that we can shrink the size of the DLL in a future release, but like Norman mentioned, the requirement is unlikely to completely disappear.

The application size is also important to us. We had planned on using a Linux Console application with Amazon AWS Lambda but it currently only allows a 20MB compressed package size. Not sure how big our app is compressed but this might not be possible anymore.

This is where static linking + dead code stripping would help in a big way.

Would there be any way to have the entire new framework stripped out? Many of us are bothered by this file size increase especially since it appears to be mandatory, even if we aren’t using Xojo.Core features at all. Using an older version of Xojo is an option of course but there are so many bug fixes in the new version (including IDE fixes) that this is problematic for other reasons.

FR - 37644
I hope I did this correct and filed it as a feature request.

Not that I can imagine given how things work.

Quite literally this would require removing the TEXT data type, the new DATE type & all formatting and anything associated with locales from the CORE language and AUTO etc. And I’m sure other components that I’ve overlooked.

This has to do with how DLL’s work, the compiler works etc
I see this is “extremely unlikely”

[quote=157441:@LangueR]FR - 37644
I hope I did this correct and filed it as a feature request.[/quote]
I can’t find 37644 - did you mark it private?

Not intentionally. Travis reviewed it and corrected it. It did not live to see the light of day :slight_smile: … But it looks like there are some improvements which will make the Linux folks happy, and “may” reduce the ICU DLL hit on Windows to around 6.5MB. Better than what it was, right?

Any idea if the 6.5MB was compressed or raw size? I wonder what that would be zipped…