> It might indeed not be useful for distros, but it looks like an interesting > option to reduce the package size
I played with this last year at Randa after we spoke about it. I heavily patched everything to bring the size down and improve startup time. QML cache doesn't help that goal at all. I ended up not using it and it made both size and startup time worst on mobile devices. The startup time is I/O bound on modern phones, not CPU bound. I am leaving for the airport so I can't write a 10 page tutorial and it isn't related to shipping QML cache. ## What doesn't help: * Compile QML (it does nothing) * Minify QML (the bundle are often already compressed) ## What help, but is broken * Using musl libc because libGl cannot be bundled and they must have the same libc * Static glibc causes 2 instances of static vars to exist and it crashes ## What is lost * The way many KF5 apps use plugins can't work in static modes (like Kio, kded5, kdeinit5) and have to be patched out. ## What helps: * Using static libraries * Using full bundle LTO (link time optimization) (reduces the bundle size by 75%+ with this alone) * Enable PGO/FDO (massive improvment in statup time) * Optimize all SVG for loading speed (reduce the Inkscape created ones by 96% and Qt loads them faster) * QRC *everything* to avoid all syscalls and blocking I/O `stat()` * Create a custom qplatform with more aggressive CXXFLAGS and LDFLAGS * Using Qt-lite * Using Gentoo "USE" system to disable optional dependency features instead of using what ships with Qt * Stripping the fonts from all the colored icons madness they recently added and QRC it. Here's an AppImage produced with the patched frameworks: http://lvindustries.net:8080/ In both case it is not fully minified. The 45mb ones lack -Os and have debug symbols. The 18mb ones are not fully stripped to get useful backtraces. I can make them ~13mb if I want, but it makes debugging impossible. To have a good comparaison, that software has mostly the same dependencies as KDenLive and their AppImage is more than an order of magnitude bigger. Note that I don't run the PGO/FDO on those builds as I havn't automated that part yet. If there is enough interest, I guess I can create a small BoF at Akademy to demonstrate and talk about how willing we are to makes this work. If we get serious about this, a lot of things have to change and new library guidelines enforced. Some people will find the new limitations imposed on them very frustrating. But the bright side is 85%+ smaller APK/FlatPak/AppImage/DMG/Snap that load multiple time faster. (related: https://phabricator.kde.org/D13816)
