Unsolved Licensing for Qt Embedded - Static build
-
@SGaist said in Licensing for Qt Embedded - Static build:
@sierdzio said in Licensing for Qt Embedded - Static build:
So, in very general terms it is OK to say that static linking is not allowed under LGPL, but such sentence should be followed with some star * and explanation in small print at the bottom of a page ;-)
It is allowed. See the GNU GPL faq about static linking and LGPL.
Yes, I know and I hope I explained it ;-) I just meant that a TL;DR summary could state that it is not allowed, simply because it requires big effort to pull it off. Anyway, that's just my opinion. I'm pretty sure the reference OP is mentioning came from Qt Company back when iOS really was not compatible with LGPL at all.
-
@sierdzio I just created simple application to verify performance between static vs shared build:
Test application creates screen which contains 60 controls (30 - QPushbutton Icon+Text, 30 - QLabel).
Timing:
Static build - 1.1 seconds
Shared build - 1.5 secondshttps://doc.qt.io/archives/qtextended4.4/qt-embedded-performance.html#static-vs-dynamic-linking
Thanks,
Hari -
OK, so here the results (both) are pretty decent. I mean 60 controls in less than 2s - that seems good to me. And you have not enabled Link Time Optimizations (right?) which might change the results considerably. It's still just a test app. Results for the final app may vary.
Anyway, I'm not saying this to discourage static builds, they are a fine solution, sure.
-
@Hariprasasth
I don't get this. I have read the link you included.So far as I understood it, the time difference in application execution between a dynamically linked vs statically linked would just be a (modest) difference in start-up time. You have one application. Once it's taken 0.4 seconds longer to start-up initially, it shouldn't make any difference whether you create 3 controls, 30 or 300, the code being executed will run at the same speed between the two. Unless there is something special about embedded which I understand nothing about.
Am I wrong, or is this a one-time half a second improvement you're talking about?
-
@JonB
Its not only about start-up. After starting-up, I tried to redraw all the controls on clicking one button. And, still I see the timing difference between static and shared (0.4 sec).Thanks,
Hari -
@Hariprasasth
And how would that come about? Would a Qt expert care to comment on how a statically vs dynamically linked set of Qt libraries can perform at different runtime speeds, after start-up? -
@Hariprasasth said in Licensing for Qt Embedded - Static build:
Timing:
Static build - 1.1 seconds
Shared build - 1.5 secondsUnless you care to provide actual statistics this has no meaning. The uncertainty of one sample is just the square root of the value of said sample, meaning for all intents of purposes those two numbers are equal.
@JonB said in Licensing for Qt Embedded - Static build:
And how would that come about?
It shouldn't.
Would a Qt expert care to comment on how a statically vs dynamically linked set of Qt libraries can perform at different runtime speeds, after start-up?
I'm no expert, but I wouldn't even hazard a guess.
@sierdzio said in Licensing for Qt Embedded - Static build:
Anyway, I'm not saying this to discourage static builds, they are a fine solution, sure.
Maybe in some specific situations, which doesn't seem to be the case here. I'd rather all the KDE apps of the Plasma desktop I'm running link dynamically (and to the same library), instead of each bundling a copy of the same thing. Also the OS's loader can optimize loading dynamic libraries (i.e. they may already be in memory), which it can never do when you link statically.
So a "fine solution" is already pushing it a bit. -
@kshegunov said in Licensing for Qt Embedded - Static build:
@JonB said in Licensing for Qt Embedded - Static build:
And how would that come about?
It shouldn't.
Thank you! My point being, from my understanding and usage of static vs dynamic, there should only be a difference at start-up time, once it's in memory there should not be any difference at runtime. And if the OP's statistics of 50%-odd difference is true/replicated, I would expect everyone to have abandoned/complained about dynamic a long time ago!
-
@JonB said in Licensing for Qt Embedded - Static build:
My point being, from my understanding and usage of static vs dynamic, there should only be a difference at start-up time, once it's in memory there should not be any difference at runtime.
No not only, but the difference should be negligible to non-existent. Probably the "major" hit comes from generating cache misses (due to indirect references) when the CPU is executing the code. I'm going to say it again, though, this should be so insignificant in this kind of code that I wouldn't even venture into considering it.
PS.
Some related resources if you're feeling curious. -
@kshegunov said in Licensing for Qt Embedded - Static build:
@JonB said in Licensing for Qt Embedded - Static build:
PS.
Some related resources if you're feeling curious.Quoting from there:
Instructions that refer directly to specific memory addresses sometimes
execute faster, and replacing them with equivalent relative-addressing
instructions may result in slightly slower execution, although modern
processors make the difference practically negligible.Here we are talking about a very weak CPU with very slow memory (104 MHz RAM according to the specification). It may well prefer static builds.
I'd still throw in LTO is the compiler for that CPU supports it (see link).
You are, of course, absolutely right that a statistical analysis of the results is necessary for proper judgement, though.