Installing qml caches

Simon Hausmann hausmann at gmail.com
Sun Jul 8 17:06:58 BST 2018


Hi,

I suspect that at the point when you measured, the qml files created ahead
of time contained the native code. Note that if they were big for your
taste, then remember that every byte there without cache files occupies
unshared memory (that can only be evicted to swap).

Since 5.11 the files are much smaller and contain byte code, in addition to
data structures that need creation otherwise.

I share Volker’s recommendation as well as yours:

Use static linking, LTO etc. for apps. And use the QtQuickCompiler build
option with 5.11.


Simon

On Sat 7. Jul 2018 at 15:04, Elv1313 . <elv1313 at gmail.com> wrote:

> > 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20180708/e18ae623/attachment.htm>


More information about the kde-core-devel mailing list