LiveCode Forums.

Good morning everyone!

Please tell me I am doing something wrong here. If I create a brand new mainstack in LC7 and drag a single button onto the canvas and then proceed to export as a standalone application, my compiled app is 8.5MB IN SIZE! This is for 1 button with nary a line of code attached. There are no embedded files or other dependencies and I have completely disabled the build options for other platforms, so I am only exporting to .exe for Windows. How can a completely empty "application" have an 8.5MB filesize?

I have written programs in AutoIt that were 500-1,000 lines of code and compiled them to .exe only to have their filesize be ~800kb-1mb. In fact, if you figure in all the custom UDFs I included into those applications, there were probably more like 3,000+ lines of code that only totaled 800kb upon compilation.

What is the source of this excessively large filesize and how can I trim the fat off of it? I deploy my apps across networks that don't always have the most bandwidth to spare, and I need something that is diminutive in size.

I am sure this is just the ignorance of a beginner. Someone educate me please!

I second that - file size for LC7 is too large.
Unfortunately there is nothing you can do to trim that fat.
Have you tried using the new "CEF" explorer now were really talking EXTREME file size,

jeffe wrote:I second that - file size for LC7 is too large.
Unfortunately there is nothing you can do to trim that fat.
Have you tried using the new "CEF" explorer now were really talking EXTREME file size,

Hi Jeffe -

Thanks for your reply. Can anyone else confirm this? An empty app should be mere kilobytes. If the app had 6,000 lines of code with graphics embedded I would expect such a large file size but 8.5mb for an empty file is woefully unacceptable. Are there really no options for optimizing filesize here?

As much as I like LC7 - I'm sticking to LC 6.7 for now. EXE is only about 2.8MB
I await to see what the livecode team will come up with.

Hopefully an option to reduce file size by selecting components required
or even reduce the size of the compiled exe.

I also just checked out autoit - and wow extremely small exe and its not hard to use.

stoavio wrote:An empty app should be mere kilobytes...

..if it were possible to build an empty app with LiveCode.

When a standalone is built, the LiveCode runtime engine is statically bound to your stack file. The size of the runtime engines for each platform can be seen in the Components/Tools/Runtime folder with the IDE install.

Lower-level languages impose a compile-runtime cycle, in which smaller executables are possible because your code is translated to native machine instructions, and with good modern compilers only those instructions needed for your specific app are there.

But of course using such a language would mean learning the lower-level APIs for each platform, manually managing memory, and all the other things that tend to go along with lower-level languages.

Like using Assembler when speed is critical, if executable file size is an absolute must-have then there are many other languages which can accommodate that. But like using Assembler, the development cost of doing so is often much greater.

One of the reasons we have so many programming languages to choose from is that each offers a different mix of benefits. Scripting languages like LiveCode have become enormously popular for applications, but any scripting language will need the core interpreter/compiler embedded with the developer's scripts to run.

So the size of any truly stand-alone executable made with a scripting language will be the size of the developer's code and objects + the size of the scripting engine.

IIRC correctly, the size of the Toolbook engine has for a long time been much larger than even LiveCode 7, and the complete Python engine is about three times as large. Even Xojo, which claims native compilation, still has a core engine that weighs in at about 4 MB.

The LiveCode engine is comprised of somewhere just under a million lines of code, so even a seemingly "empty" app is far from empty.

Version 7 is a superset of capabilities beyond any version before it, and the additional size accommodates some very nice automatic encoding detection and management for Unicode, along with a number of other new features.

For the future, the team is exploring ways to possibly support factored runtime building, in which unused elements of the engine may be omitted from the build. But given the way so much of the engine is integrated across various internal elements, it remains to be seen how practical that will be. But they are looking into it, and it'll be interesting to see what they come up with.

For now, if you don't need Unicode then 6.7 is a fine choice. Its engine is about two-thirds the size of Apple's Calculator app, and about half the size of a majority of apps on my phone.

I don't mind the size so much.
I'm happy my stuff is getting to work
These days with big memory, huge hard disks, super fast processors, what is a few MB's.

It's great, it's easy, it's fun, it's free, it's fast, it's giving results, forum support is fantastic, i love it.

FourthWorld wrote:

stoavio wrote:An empty app should be mere kilobytes...

..if it were possible to build an empty app with LiveCode.

When a standalone is built, the LiveCode runtime engine is statically bound to your stack file. The size of the runtime engines for each platform can be seen in the Components/Tools/Runtime folder with the IDE install.

Lower-level languages impose a compile-runtime cycle, in which smaller executables are possible because your code is translated to native machine instructions, and with good modern compilers only those instructions needed for your specific app are there.

But of course using such a language would mean learning the lower-level APIs for each platform, manually managing memory, and all the other things that tend to go along with lower-level languages.

Like using Assembler when speed is critical, if executable file size is an absolute must-have then there are many other languages which can accommodate that. But like using Assembler, the development cost of doing so is often much greater.

One of the reasons we have so many programming languages to choose from is that each offers a different mix of benefits. Scripting languages like LiveCode have become enormously popular for applications, but any scripting language will need the core interpreter/compiler embedded with the developer's scripts to run.

So the size of any truly stand-alone executable made with a scripting language will be the size of the developer's code and objects + the size of the scripting engine.

IIRC correctly, the size of the Toolbook engine has for a long time been much larger than even LiveCode 7, and the complete Python engine is about three times as large. Even Xojo, which claims native compilation, still has a core engine that weighs in at about 4 MB.

The LiveCode engine is comprised of somewhere just under a million lines of code, so even a seemingly "empty" app is far from empty.

Version 7 is a superset of capabilities beyond any version before it, and the additional size accommodates some very nice automatic encoding detection and management for Unicode, along with a number of other new features.

For the future, the team is exploring ways to possibly support factored runtime building, in which unused elements of the engine may be omitted from the build. But given the way so much of the engine is integrated across various internal elements, it remains to be seen how practical that will be. But they are looking into it, and it'll be interesting to see what they come up with.

For now, if you don't need Unicode then 6.7 is a fine choice. Its engine is about two-thirds the size of Apple's Calculator app, and about half the size of a majority of apps on my phone.

That was an elegant response and you make a lot of good points. Factored runtime building would be a welcome feature and one that would make the resultant applications more portable. I know ~9MB doesn't seem like a lot in this day in age with internet speeds what they are, but because LC is such a versatile language, it's easy to want to use it for the construction of even quick/small projects where you would expect the filesize to be nominal, and where you may need the program to be light and nimble.

This is by no means any kind of deal breaker for me. LC has a lot to offer and I have a lot more to learn. I was just surprised and thought maybe I was doing something wrong. I'll explore packing my application as a self-extracting zip file to reduce its filesize in transport.

One point of clarification if I may: What are the distinct advantages between using 7 over 6.7? I know you mentioned Unicode. Is that it? If not maybe it would behoove me to use 6.7 instead, just as long as I am not sacrificing major feature functionality.

@Sphere: I can't contest any of those points.

__ __

My Livecode 7 files starts from 3kb to 119kb.
The 119kb it's a very complex mobile app. (4 cards, SQLite db management, datagrids, 2 language localization, a lot of buttons and so on...)
The most big LC7 source is 1.4 kb. (and it's a huge enterprise level stack, DB, PDF generation, a lot of substacks, autogeneration of restricted version copies of itself, ... ). Even this way the standalone that include images in itself reach just 9Mb. Compared to other products is just small as browser plugin.
I don't see any problem.
I mean, I program on source, and the source is incredibly small. The size of the exe doesn't count for the user.

Unicode is the biggest draw, and for Linux users there's been substantial enhancements to LiveCode's integration with GDT.

For any other details, check out the Release Notes accompanying the v7 release (accessible from the Help menu).

Edit: I just stumbled across this page at the LiveCode site that highlights some of the strongest points of v7:
http://livecode.com/livecode-7/

Interesting to see the runtimes of 7.1.1
iOS 25,1 MB
Android 12,7 MB
Linux 11 mB
Mac OS 11,6 MB
Windows 9,8 MB

iOS is almost double the size of the rest... wonder why, especially when compared to the Mac OS runtime. Native iOS apps can be really small depending on features and I guess the LiveCode engine IS native.