Compiled size

Older versions of RB were quite good at not linking-in plugins, code, dynamic constants etc… that were not referenced in active code. Unfortunately, over the years, the compiler / linker seems to have become dumber and doesn’t strip out as much leaving you to go on a fact finding mission to remove unused stuff from your project manually.
I logged various cases about this and was told it was because of introspection. My projects don’t use introspection so I personally don’t see why the linking process couldn’t be as efficient as it used to be.

The size of executables is of concern to me as they just seems to be getting bigger and bigger without any significant benefit. Unfortunately, it seems like the majority of the Xojo framework has been designed as a monolith so we have no control over what gets included. In an ideal world, the Xojo framework would be implemented as plugins so that they were only included when necessary. In reality, that probably isn’t a trivial thing to implement and i’m sure they have more important things to tackle at this present time.

You can use MBS for sending email and get a plugin linked in with smaller size.

If the compiler genuinely includes plugins that aren’t being referenced, we really could do with a Plugin Spy that tells you which plugins ARE needed in the project.
Pulling them out one by one to see what squeaks is painful, and I gave up trying a long time back.
But the bulk of the size hike is the framework.

You can put them together i 1 folder then have the “Appname Libs” folder renamed to a single “Libs” folder. That would actually make it smaller than it was.

[quote=354129:@Jeff Tullin]If the compiler genuinely includes plugins that aren’t being referenced, we really could do with a Plugin Spy that tells you which plugins ARE needed in the project.
Pulling them out one by one to see what squeaks is painful, and I gave up trying a long time back.
But the bulk of the size hike is the framework.[/quote]

I can’t remember the exact scenario now (it is logged in Feedback somewhere) but it was something along the lines of:
if you had a method containing code that accessed a plugin but your main code didn’t call that method, the plugin would still be included. Similar for dynamic constants. The version of RB we mainly used would strip them all out.

Methods are not stripped as they may be called via introspection.
But I several times asked to also strip them by choice.
e.g. strip all which don’t have #pragma to force inclusion.

Xojo (realbasic) has never stripped at the level of a single method
So if you have class with a method that depends on a plugin, but that method is not called, the plugin IS (and always has been) included since there is a dependency - and one that cannot be statically determined since you could instantiate the class dynamically and call the method via introspection.
A module is similar.

But, this notion that “if the framework were built as plugins apps would be smaller” is mostly not the case.
Why ?
Suppose we split out strings , folder items and everything into separate plugins

The FolderItem plugin would depend on the string one - because it uses strings
Building a desktop app the App instance has dependencies on strings, folderitems, tray items, runtime exceptions, etc
Why ?
Well look at the properties methods & events and every event parameter is a dependency, every method parameter is a dependency, and every property is a dependency.
And then you have to look at those things to see what other dependencies there are.

Strings rely on ICU because thats how strings work - so we’d have to include that

By the time you make even a very simple application the list of dependencies is very long
In fact I’d expect you’d have the entire framework

[quote=354144:@Norman Palardy]Xojo (realbasic) has never stripped at the level of a single method
So if you have class with a method that depends on a plugin, but that method is not called, the plugin IS (and always has been) included since there is a dependency - and one that cannot be statically determined since you could instantiate the class dynamically and call the method via introspection.
A module is similar.

But, this notion that “if the framework were built as plugins apps would be smaller” is mostly not the case.
Why ?
Suppose we split out strings , folder items and everything into separate plugins

The FolderItem plugin would depend on the string one - because it uses strings
Building a desktop app the App instance has dependencies on strings, folderitems, tray items, runtime exceptions, etc
Why ?
Well look at the properties methods & events and every event parameter is a dependency, every method parameter is a dependency, and every property is a dependency.
And then you have to look at those things to see what other dependencies there are.

Strings rely on ICU because thats how strings work - so we’d have to include that

By the time you make even a very simple application the list of dependencies is very long
In fact I’d expect you’d have the entire framework[/quote]

Hi Norman.

Older versions of RB (ie: before Introspection) did a much better job stripping stuff out. As I mentioned, I logged two - maybe three Feedback cases when we first moved from RB to Xojo and noticed how much stuff was now being included.

Did you mean text relies on ICU rather than strings? Yes, i’m sure there would be dependencies and things like strings / folderitems should probably be part of a core. At the same time, we don’t use the new framework or the movie player so we shouldn’t be burdened with those resources in our built application.

The inclusion of the plugins isn’t really a problem. I just whine about the size because my internet connection is so slow and uploading such a large file takes so long. Doing a build: couple of minutes. Uploading the build: over an hour.

Possibly relevant - http://developer.xojo.com/techinfo/plugins has some old info as it suggests one can still make a single-file-exe if you avoid using plugins, which I think has not been possible since 2011 R3. I’ve submitted a request to update that doc.

Curious: where do you live and what is your speed? That sounds like you must live in the third world, or possibly in the USA? :wink:

@Michael Diehr: south-west Germany - 50 km from Frankfurt, just beyond the city limits of the next city.

I have 1.5 MB for DSL. The next access to cable is 70 meters away. LTE only has 50 GB and I have easily 70 - 100 GB per month.

At the start of this conversation, I checked my Plugin folder: I changed its name very long time ago (2015r1).

Since I only use SQLite, and I never get any Plugin(s), I do not have troubles with these.

A check can easily be done: quit Xojo (if it is running), move the DB plugins from the Plugin folder, fire Xojo, build your application.
Check the application size.

[quote]@Jeff Tullin So was that part of the XojoGUIFramework.DLL?
That single DLL jumped in size, but I see no sign of ICU as a separate ‘thing’ … I had expected to see an ICU.DLL or similar
From what I can remember it was originally a separate dll and in a later release merged in to reduce the size.[/quote]

Further checking: in Xojo 2015 build compared to 2014, the XojoGUIFramework leaps to 23Mb, but the build ALSO creates ICUDT.dll which is another 10Mb.

I don’t see any problem with the Xojo compiled size app. Xojo framework is a small native cross-platform framework(take a look at QT size), on windows they had to include ICU library to support Unicode (so is a must). If you really want to decrease the size of XojoGUIFramework32.dll, you can use UPX (https://upx.github.io) but the dll will be decompressed in the memory (so your app will use more memory).

On windows they had to include ICU to support the Text object for the new framework - which I am not alone in not using.
The new framework was to support iOS, which I’m not using.

I was doing Unicode fine before ICU…

It’s obviously too late to moan now.
The new framework comes along for the ride, wanted or not.
And the distribution size just keeps getting bigger.

For other projects , yeah OK, I’ll live with the size.
If anyone complains how long they take to download I’ll point them here… :wink: