@ChristianM was curious on the numbers of the HTML5 build too, so I started doing the same for that platform too.
While looking at the numbers, we started discussing more and more things we wanted to remove or try removing.
A classic, it’s just too fun to not start optimizing a bit while at it ^^

Here’s the bigger things I did:

ndebug means I compiled with -DNDEBUG. It removes the asserts() and the strings they contain. It also removes various amounts of debug code.

<libname> means I removed that lib or functionality. Either statically, or using the app manifest.

I removed the logging macros, and profile, debug rendering and the built in Connect App from dmengine_release. This should save ~200kb for each platform in the release build

After building, I gzipped the custom built dmengine.js from the native extension build

The NDEBUG option shaves off an extra ~30, but that also means we internally have to update more
on our build system side (and on the Native Extension server), so that will have to come a little later. There are easier things to do first.

I feel confident that the executable can be even smaller. We have a few other options to explore that will take various amounts of time to implement. Both in general, but also depending on what features you actually need.

Hopefully, this added functionality should land in a release soon

EDIT:
Here are numbers on some of the source .js files I compressed for the test:

Of course!
I got so excited about the release I had forgot to prepare my notes… ^^

Customizing the engine build

Apart from specifying your own new extensions, you can also enable/disable libraries via the "App Manifest"
This is a feature that has very little documentation yet (none?).
The basic idea is that it should work very closely to how the extension manifest works (and also our master config for the server).
And although this config design isn’t fully nailed down, we think it’s beneficial your you to get access to this alpha feature so you can
start playing with it (or release with it!).

Config

There are a few new keywords, in perticular: excludeLibs, excludeSymbols, excludeJars which allow you to remove libraries and C++ symbols and also .jar files.
Using the libs keyword, you can add engine libraries, and using symbols you can add engine symbols

Future

Currently, there are not a whole lot of options for you to play with, and to be honest, we’d like to improve on this a lot.
It’s not extremely user friendly to modify a build like this. We’d like more.
What we’d like, is to categorize the engine into more extensions (or features), and allow you to select those features you actually need.
Or, perhaps we could detect this as well: removing components or script modules you don’t use.

How to

Below, you’ll find the three most asked for build variants.
Enabling these is straightforward, albeit a little hiddeen:

One issue that will arise more and more regarding adding extensions, is getting link errors due to duplicate symbols. This is not an uncommon problem but it’s fairly easy to remedy if you have full access to all steps in a compile pipeline.

However, since this isn’t possible in a closed system, we have to use other means to resolve it.

Currently, the engine only has a few composite libraries, which include parts of other libs (e.g. some crypto functions). This makes it impossible to remove “just that part” from the engine. Instead, you’ll have to instead rename your incoming symbols. In effect, you have to rename all colliding functions in that library, and recompile that library before using it. A common trick is to rename from “apiFunction()” to “apiFunction2()”, and then you use apiFunction2() in your code.

Of course, that means more work for you users, and we want to make it easier, so we are going to look into splitting our larger libraries, so you can exclude more parts of it, in favor of your new(er) versions.

I tried stripping only the physics out to see the implications on memory and package size. May as well dump my findings here.

Because I didn’t want to spend too much time I only tested on macOS builds, the memory could differ from device to device though so keep that in mind. I built each version for macOS and got the memory with profiler.get_memory_usage(). I restarted the whole game after each sample and I used 9 samples. Testes done with engine version 1.2.117 and in release mode.

TLDR; The package size decrease is nice but memory implication is pretty meh.

Memory

Data of an empty project, with physics

The data collected indicates that each collection proxy adds 0.36 MB of memory.

Data of an empty project, without physics

Empty

5 Collections from file

5 Collection Proxies

5 Collection Proxies - Loaded

Average MB

38.6

38.4

38.6

40.2

Average Bytes

38600704

38420024

38642574

40194048

Interestingly the data we get now for 5 collection proxies loaded is 1MB lower compared to having it with physics, but it is also still 1.8 MB over the other values. The memory added per collection is 0.36, meaning a 0.09 difference between with and without physics.

Package size

With

Without

Diff

Diff -MB

Android

2801489

2491918

-309571

-0.3

iOS

2619459

2263253

-356206

-0.35

macOS

5408039

4230099

-1177940

-1.2

Other observations

profiler.get_memory_usage() is broken, doesn’t indicate that memory is released and only counts up. Making it only really reliable on build/app start.

If you have physics objects in your build and strips physics out the build will not be able to start but will not give any errors as far I noticed.

I should (but most likely won’t) test it out on android and/or iPhone to investigate if it is comparable with macOS.