How to reduce openfl size?

Hi,

I’m building a very small iOS application. But OpenFl adds many megabytes. Can I remove unused libraries (sound, network, freefont, etc) ?
Maybe I can modify the build process ? Removes some files from Export/ios//haxe/build/Release-iphonesim/obj/iphonesim-c11/

Romain

Do you have dead code elimination enabled?

<haxeflag name="-dce" value="full" />
1 Like

Did you already try to compile with -dce full to remove unused code?

I think that dce will reduce executable size. If You want reduce lime.ndll, You probably could download lime dev version and edit file Build.xml in lime/project folder:


From the thirteenth line, You should be able to swap for example

<set name="LIME_FREETYPE" value="1" />

into

<set name="LIME_FREETYPE" value="0" />

to disable this part. And rebuild lime.

1 Like

thanks for the ideas :slight_smile:
dce flag works fine and reduce the size of my application, but the openfl libraries are not reduce. The libraries are much bigger than my program.

I build the dev version of lime. But my project doesn’t build with the dev version:

openfl build ios
[Compiling]
ld: warning: object file ([project]/Export/ios/build/Openfl.build/Release-iphoneos/Openfl.build/Objects-normal/armv7/Main.o) was built for newer iOS version (5.1.1) than being linked (5.1)
Undefined symbols for architecture armv7:
"_GCControllerDidDisconnectNotification", referenced from:
_SDL_SYS_JoystickInit in liblime.a(e34af468_SDL_sysjoystick.o)
_SDL_SYS_JoystickQuit in liblime.a(e34af468_SDL_sysjoystick.o)
"_GCControllerDidConnectNotification", referenced from:
_SDL_SYS_JoystickInit in liblime.a(e34af468_SDL_sysjoystick.o)
_SDL_SYS_JoystickQuit in liblime.a(e34af468_SDL_sysjoystick.o)
OBJC_CLASS$_GCController”, referenced from:
objc-class-ref in liblime.a(e34af468_SDL_sysjoystick.o)
ld: symbol(s) not found for architecture armv7

I follow the instruction from the https://github.com/openfl/lime#building-from-source page. What is wrong ?

I also try to build on Linux. I get the dev version of lime, build it. I compile my application with dce. It works. I remove some flag (sound or zip or jpeg, etc) of lime Build.xml and rebuild lime and my application.

When I launch my application :
Could not find primitive lime_al_delete_source__prime.
Could not find primitive lime_al_get_sourcef__prime.
Could not find primitive lime_al_source_play__prime.
[…]
Could not find primitive lime_cairo_pattern_set_extend__prime.
Could not find primitive lime_cairo_pattern_set_matrix__prime.
Could not find primitive lime_cairo_surface_flush__prime.
Segmentation fault

I don’t use sound. My test project is only “class Main extends Sprite {public function new () {super ();}}”. Why OpenFl/haxe load it ?

@Retard: Thanks to show me Build.xml. The value (1 or 0) have no meaning. The flag is defined or not .

Well, generally if You encounter errors like [quote=“Romain, post:5, topic:7329”]
Could not find primitive lime_cairo_surface_flush__prime
[/quote]
then flag works . There should be also edit of /lime/app/Application.hx (and maybe other) file - You should remove parts of code that e.g. initialise sound - when app is starting, it triggers mentioned functions by default. If they are not present in ndll, You have to comment them out in hx files.

Ahh, right, You should also remove parts:

<include name="lib/cairo/files.xml" />

from Build.xml

Edit:
And I think that graphics are tightly integrated into library. Easier would be to remove freetype and harfbuzz first and check whether it works. Then nfd, audio, png, jpg, lzma, etc. Graphics will be hard to remove, because there probably would have been changes in events also. And I can’t help You with IOS dev unfortunately.

And about removing functions: try grep in top lime folder:

grep -rn /lime -e "lime_al_delete_source"

You should have list of hx files which are using this func with line they occur also. Then try to comment out invocation of this function.

Ok. Add flags in the project.xml to activate/disable some libraries.
It will need a lot of work. Does the openfl community will use it ?

The name of the flag are pretty obvious.

LIME_CAIRO: It’s 2d graphics.
LIME_CURL: for loading files from url.
LIME_JPEG: for jpg picture.
LIME_FREETYPE. For text.
LIME_HARFBUZZ. For text.
LIME_LZMA. For compression.
LIME_NFD. For text ?
LIME_OGG. For sound
LIME_OPENAL. For sound
LIME_OPENGL. For opengl driver.
LIME_PIXMAN For pixel manipulation.
LIME_PNG for png picture.
LIME_SDL For many thing ?
LIME_SDL_ANGLE for opengl es emulation on windows phone ?
LIME_VORBIS For sound
LIME_ZLIB For compression.

is SDL or cairo mandatory for opengl ?

1 Like

nfd is Native file dialog, unified file or folder selector window.
I don’t know what the role of cairo in lime is, SDL is needed I think - AFAIK joystick, events, displaying is done with SDL.

There are some defines in the Lime include.xml, such as “lime-openal” and such which were put in for allowing disabling of certain library dependencies, though over time, the code has come to rely on these pieces being available, so we may have a little cleaning and adding of guards in the code if we’re going to fully allow this.

SDL provides the basic layer on iOS, so you need that. Cairo provides a software renderer, which OpenFL relies on. OpenAL is not compiled on iOS since the platform includes it already. OGG and Vorbis are used for OGG sound decoding. Harfbuzz and Freetype are used for text. Pixman is a Cairo dependency. PNG and JPEG are for image decoding, zlib is for zip decompression/compression (such as in ByteArray or used by other libraries

iOS compiles static binaries by default, which exaggerates the size. When you compile to a final iOS binary, it should pull only the symbols needed, and be much smaller. I think we’re around 5MB or so for Lime, which is probably reasonable. What do you think?

Quite frankly, I have stopped looking at the size of finished application packages, on all platforms.   It simply doesn’t matter anymore.   (And if it does, tell your grandparents to pony-up and buy a new phone…)   :wink:

My tiny openfl application is only 3Mo on iOS. It’s not very small, but it’s ok.

Some time ago I happily built a one-page website using the Bitfive backend. The JS file was only 135 kb uncompressed. I recently did a test with the OpenFL HTML5 backend, using DCE full and the JS file is 542 kb uncompressed. This makes it rather unwieldy to use for a website. Is there a way to reduce that or should I simply keep using Bitfive in future projects?

Did you try -final? I think we could do more investigation into improving minification and DCE performance from core OpenFL

Using -final (openfl test html5 -final) the file went to 278 kb. Much better but still room for improvement. Thanks!

I am noticing that -final does a minify on the code. Presumably it’s not doing any more DCE.

yep, DCE + minify, but we should look at ways to reduce the amount of code more and to allow things to minify better to get it tighter long-term :slight_smile: