8

The size of application with all needed .dll files is very big (almost 30 mb). How I can reduce this size?

iVi
  • 81
  • 1
  • 2
  • 2
    Do not use Qt. Semi-joke aside, you need to look into the selection features to include the things you really need, but this has been untested and anyway, Qt is just goliath by default. – László Papp Jul 01 '14 at 14:18
  • Do you know good light alternatives to Qt? – iVi Jul 01 '14 at 14:23
  • 1
    Sure, [fltk](http://www.fltk.org/index.php) is what we use on resource critical embedded, although you can even strip that down with an own solution to get rid of X, etc. Even with X, it is 1 MB or so. ;-) – László Papp Jul 01 '14 at 14:24
  • 1
    Do you sure that it will be so small at Windows? Qt application without libraries is very small at Linux (for example, KDE). – iVi Jul 01 '14 at 14:29
  • 2
    No, Qt is not small. QtCore is >4MB and then you do not yet have any graphics. If you mean a raw C++ application not using Qt, obviously, that is small, but that is not a Qt question. ;) – László Papp Jul 01 '14 at 14:30
  • 1
    I talking about the situation when all packages are installed. I know that it is offtopic, but if there are other languages and frameworks that are light, strong and cross-platform tell me. – iVi Jul 01 '14 at 14:34
  • 1
    @FinalContest I'd understand this coming from someone who doesn't use Qt all that much, but from you? I develop statically compiled Windows applications that depend on Windows DLLs only (no MSVC redistributable etc.) that take about 5-6Mbytes after compressing with UPX. That is the app code + VC++ runtime + C runtime + Qt core, gui, network. So I'd say that unless someone is doing things seriously wrong, Qt is actually quite lightweight. I mean, all this functionality has to come from *somewhere*. – Kuba hasn't forgotten Monica Jul 01 '14 at 14:56
  • No, that is the whole point. "All this functionality" should not be coming from anywhere at all, not even speaking of QtGui and other goliaths. There is shitload of stuff in QtCore which is completely unnecessary to render a rectangle. Further, not that I am not using Qt all that much, I am not using it at all for said reasons. It is simply out of the question for very minimal embedded. – László Papp Jul 01 '14 at 14:58
  • A simple solution is to build a completely static executable with no dependencies on either Qt or MSVC runtimes. I have answers detailing [how to pull it off for both Qt 4 and Qt 5](http://stackoverflow.com/q/21862989/1329652). – Kuba hasn't forgotten Monica Jul 01 '14 at 14:58
  • @FinalContest Whatever code you don't call will not end up in the executable. That's the beauty of link time optimization and static linking. It tends to make the executables small and fast. – Kuba hasn't forgotten Monica Jul 01 '14 at 14:59
  • @KubaOber: not really, no. The whole QtCore is hardwired into many dependencies right from the beginning. Even a simple QString needs a QCoreApplication to run properly, but that is just one example of those. I am not trying to talk hatred bullshit here. I have spent a lot of time with evaluating fltk and Qt for real embedded in professional time. Even your example says 5-6 MB with all the super compression, whereas I can do what I want out of a few hundred kilobytes without super compression. Now, guess whether we have 5-6 MB on a 8 MB flash or less... – László Papp Jul 01 '14 at 15:00
  • @iVi: `I talking about the situation when all packages are installed.` when really all installed, Qt loses all the games possible with defeating game over ;) – László Papp Jul 01 '14 at 15:03
  • Me don't need so lightweight application. 5-6 MB is a good size. – iVi Jul 01 '14 at 15:03
  • Kuba Ober, how you get it? – iVi Jul 01 '14 at 15:04
  • @iVi: what he says is partially impractical. You will not be able to update the dll without rebuilding your application. It depends on your use case. Also, the "gain" will be instantly lost with more than one application. The proper way of doing is using the features system which was meant for this use case you are asking. That will work in any of those scenarios, and also much more flexible. – László Papp Jul 01 '14 at 15:05

2 Answers2

7

In theory, you can do any of the following:

  1. Disable the Qt features you don't use. See the official documentation on the subject.
  2. Use an older Qt version, which has less dependencies on e.g. ICU and less libraries in total.
  3. Build everything with link-time optimizations, including the Qt DLLs. Your mileage may vary (you might even get bigger, but faster in the process).
  4. Build everything statically, and link only what you need. Note that this strongly depends on the capability of the linker and compiler to eliminate dead code. This may or may not prove worthwhile: usually, most of a DLL's contents are used, so you may only shave off a MB or so. Some compilers (notably MSVC) cannot cope with the object file size this results in (maybe only when combined with #2).
  5. Don't care: we live in the age of broadband internet. Compress your distributed package with e.g. 7z to minimize download time.
  6. Compress your binaries with something like UPX. Will partially mitigate #4.

I'd just go with 4.

rubenvb
  • 74,642
  • 33
  • 187
  • 332
  • 3
    There are too many bad solutions for me, for example, I can't use older version and build this application statically. But I will try do something of them. – iVi Jul 01 '14 at 14:31
  • Careful that static linking means that you've purchased a Qt license and that you're no longer using on the LGPL terms. – Adham Zahran Mar 19 '18 at 21:28
  • @Adam that is incorrect. If you provide binaries of your code (if someone asks) that can be linked to a different Qt build you can still satisfy the LGPL. – rubenvb Mar 19 '18 at 21:50
  • @rubenvb I said nothing about dynamic linking to a different Qt build. I am saying that static linking is illegal if you did not purchase a Qt license. – Adham Zahran Mar 20 '18 at 11:54
  • 3
    @Adam I'm saying you're wrong. If you provide object files that can be linked to a different build of Qt (statically), on request, you'll have fulfilled the LGPL (granted you also make any modifications to Qt public as well). This is for the static linking case. – rubenvb Mar 20 '18 at 12:04
  • 1
    Thank you for the clarification! I did not know that. – Adham Zahran Mar 20 '18 at 18:09
  • Why is statically linking reducing more size than dynamically?? I would expect the opposite. – jaques-sam Dec 13 '18 at 09:05
  • 2
    @DrumM when linking statically, you theoretically know exactly what code is never ever used and you can throw that out. When linking dynamically, you only know this per library, so each library will therefore contain at least as much code as it needs, plus everything your separate application never really uses. – rubenvb Dec 13 '18 at 09:33
  • 1
    @rubenvb: indeed, thanks for the explanation. It's possibly a bad design choice when that happens. A dynamic lib can be loaded at run time, but that can have other implications... – jaques-sam Dec 17 '18 at 10:41
2

Other than the generic principles (strip the binary, do not use QML if you are happy with C++, etc), I think you need to use configure for this to disable the features you do not need:

Including or Excluding Features

The -feature- and -no-feature- options include and exclude specific features, respectively, where is listed in the file qtbase/src/corelib/global/qfeatures.txt. For example, to disable Accessibility, provide -no-feature-accessibility as the argument:

./configure -no-feature-accessibility

Disclaimer: you are in your own territory with this, so you may end up having lots of issues that you need to fix up.

László Papp
  • 51,870
  • 39
  • 111
  • 135