[Development] Minimal static QML application binary

Jari Helaakoski jari.helaakoski at qt.io
Wed Nov 29 15:24:46 CET 2023


Hi community,

We have a task to make QML application memory footprint as small as possible and research, test and document it. I have used feature flags(https://qtlite.com/) and some other means and got helloworld app from 64Mb (dynamic linking) / 30Mb (static linking + LTO) to around 8-9Mb with static linking and LTO. I would like to hear your opinion about some findings and development items.

Two of the first items are related on application CMake interface.

  *   .rela.dyn section is over 1 MB by default. I found that -no-pie linker option in application CMakeLists will help. This option reduces security, but it might be that target application does not have external interfaces which would require extra security features. Should the flag be enabled by default or should we have this wrapped in to ie. qt_add_executable
  *
.strtab section is over 5 MB by default. Binary "strip-all" option will help. This option reduces at least debuggability, but it might be that target application has so little memory that debugging needs to be done externally anyways. Is .strtab used for anything else? So should we have wrapper option for example in qt_add_executable.
  *   These two items of course can be just documented, but what's your opinion?

The Third big item topic is template usage. Is there something that we could do with QList, QSet, QSharedPointer, QHash and especially QarrayDataPointer, which are contributing 1 MB into binary size? In example could we move generic logic into common baseclass?

Fourth item is to add more constexpr into these fundamental classes, so that global constant variables would be already generated during compile time. Or should we use standard library in cases where we want compile time code generation?  C++ 20, 23 and even 26 would bring neat helpers for this, but what's the scheduled for jumping to a newer standard?

In theory constexpr QVarLengthArray should be already now possible, but in practice (without refactoring) it requires following feature:
202306L
(C++26)
Constexpr cast from void*: towards constexpr type-erasure

constexpr QString, QList and other dynamically allocated memory containers
201907L
(C++20)
Operations for dynamic storage duration in constexpr functions

constexpr variant of Q_GLOBAL_STATIC macro
202211L
(C++23)
Permitting static constexpr variables in constexpr functions


-Jari


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231129/622f678d/attachment-0001.htm>


More information about the Development mailing list