Qt5 QApplication execution speed

[kangaba]

Hi,
I'm switching to Qt5 from Gtk3 and I noticed "QApplication app(argc, argv);" takes ~600ms to execute (cold) or ~200ms (subsequent).
That's a lot compared to "Gtk::Application app(argc, argv)" which is ~50ms.

Is it because Qt5's QApplication is always this slow or because it needs to run in its native environment (which would be KDE 5 I guess which is not finished yet)?

Using Ubuntu amd64, intel core i5, lots of RAM.

Can anyone please check how quickly Qt4's "QApplication app(argc, argv)" executes under KDE4?

[wysota]

QApplication loads a bunch of files (e.g. plugins) on startup, that might be the reason it appears slow. It is hard to say without more info why it is slow on your particular system.

[ChrisW67]

... and no, it has nothing to do with KDE version.

[kangaba]

Thanks,
one should only load the modules to be used and load the others dynamically - I had this issue with the C++ backend of gstreamer and the guy behind it actually fixed this (which is rare, typically devs are unwilling or busy), I'm not sure if the Qt guys are also so careful about startup speed (so far it seems they're not), we'll see, but first I'll test how quickly a qt4 app starts under KDE4.

[wysota]

As I said, the slowdown might be caused by your particular system configuration. How are you measuring the speed by the way?

[kangaba]

As I said, the slowdown might be caused by your particular system configuration. How are you measuring the speed by the way?
It's not specific to "my configuration", I tested both the stock qt 5.0 from Ubuntu 13.04's repos and qt 5.1 which I compiled from source - same outcome.
As to how I measure, also simple: clock_gettime(CLOCK_MONOTONIC_RAW, ...) before and after QApplication (argc, argv) and compute the difference.

In case you care here's what the mtl::misc::Timer class looks like:

Timer.hpp:

#ifndef MTL_MISC_TIMER_HPP_
#define MTL_MISC_TIMER_HPP_

#include "../err.hpp"
#include "../misc.hpp"

#include <stdint.h>
#include <time.h>

namespace mtl {
namespace misc {

class Timer {
public:
Timer(const bool do_start = false) {
if (do_start) Start();
}

virtual ~Timer() {}

uint32_t
GetMicro() {
return mtl::misc::GetDiffMc(last_time, now_time);
}

uint32_t
GetMs() {
return mtl::misc::GetDiffMs(last_time, now_time);
}

void
Print(const char *comment, const bool do_stop = true);

void
Start() {
clock_gettime(CLOCK_MONOTONIC_RAW, &last_time);
}

void
Stop() {
clock_gettime(CLOCK_MONOTONIC_RAW, &now_time);
}

private:
DISALLOW_COPY_AND_ASSIGN(Timer);

struct timespec last_time;
struct timespec now_time;
};

} // namespace misc
} // namespace mtl

#endif


Timer.cpp:

#include "Timer.hpp"

namespace mtl {
namespace misc {

void
Timer::Print(const char *comment, const bool do_stop)
{
if(do_stop) {
Stop();
}

uint32_t diff = GetMs();
const char *symbol = "ms";
if (diff == 0) {
diff = GetMicro();
symbol = "μs";
}

printf("%s: %d %s\n", comment, diff, symbol);
}

} // namespace misc
} // namespace mtl

Usage:


mtl::misc::Timer timer(true);
QApplication app(argc, argv);
timer.Print("qapp creation");

[wysota]

It's not specific to "my configuration", I tested both the stock qt 5.0 from Ubuntu 13.04's repos and qt 5.1 which I compiled from source - same outcome.
On the same computer or not? If the same (or similar) then both used the same system configuration. I don't mean the configuration of Qt but rather your particular hardware+software+user settings combination.


As to how I measure, also simple: clock_gettime(CLOCK_MONOTONIC_RAW, ...) before and after QApplication (argc, argv) and compute the difference.
Does it measure real time difference or amount of cpu time the process used? The former is useless for reliable benchmarks.

My unreliable benchmark (done using QTime::elapsed()) shows that in Qt4 the initialization times are as follows:
QCoreApplication - ~4ms
QApplication - ~75ms

For Qt5:
QCoreApplication (cold start) - 7ms
QCoreApplication (warm start) - 1ms
QApplication (cold start) - ~280ms
QApplication (warm start) - ~230ms

I'm guessing much of that 0.2s is taken by xcb but that's just a wild guess.

[ChrisW67]

It's not specific to "my configuration", I tested both the stock qt 5.0 from Ubuntu 13.04's repos and qt 5.1 which I compiled from source - same outcome.
... And the entire environment in which the program is running has not changed... You have not done anything like remove your configuration from the equation.

[kangaba]

On the same computer or not? If the same (or similar) then both used the same system configuration. I don't mean the configuration of Qt but rather your particular hardware+software+user settings combination.

Of course on same computer. If otherwise and I didn't mention it it'd mean I'm trolling.



Does it measure real time difference or amount of cpu time the process used? The former is useless for reliable benchmarks.

I provided the source code and a usage example.



My unreliable benchmark (done using QTime::elapsed()) shows that in Qt4 the initialization times are as follows:
QCoreApplication - ~4ms
QApplication - ~75ms

For Qt5:
QCoreApplication (cold start) - 7ms
QCoreApplication (warm start) - 1ms
QApplication (cold start) - ~280ms
QApplication (warm start) - ~230ms

I'm guessing much of that 0.2s is taken by xcb but that's just a wild guess.
Now we're getting somewhere, thanks. So QApplication with Qt5 is 230ms vs Qt4's 75ms - that's a big diff.

I don't think it's xcb to blame since (as a replacement for xlib) it's used to speedup not slowdown the system, so imo it's because qt5 ... doesn't run inside KDE5 but inside KDE4 which is why qt4 is so much quicker ... EDIT, not sure about the latter since I'm not sure if you ran the qt4 benchmark under KDE4.

[wysota]

Of course on same computer. If otherwise and I didn't mention it it'd mean I'm trolling.
Well then your test is useless :)


I provided the source code and a usage example.
The test is unreliable.


Now we're getting somewhere, thanks. So QApplication with Qt5 is 230ms vs Qt4's 75ms - that's a big diff.
Qt5 uses QPA, Qt4 doesn''t. Hence my guess about xcb being the reason.


I don't think it's xcb to blame since (as a replacement for xlib) it's used to speedup not slowdown the system
What I meant is that Qt5 has to load and initialize the xcb plugin whereas Qt4 just makes a direct call to X11.


so imo it's because qt5
$ ./a -platform xcb
212 ms

$ ./a -platform offscreen
6 ms

Care to continue the discussion about xcb and Qt5?


doesn't run inside KDE5 but inside KDE4
There is no such thing as KDE5.


which is why qt4 is so much quicker
Now that's a load of...


... EDIT, not sure about the latter since I'm not sure if you ran the qt4 benchmark under KDE4.
Yes, I have. KDE has nothing to do with it though. Maybe with the only difference that since I'm using other Qt4 apps, Qt libraries are already preloaded into memory but since the pseudo-benchmark is started after the libraries are already loaded, it has no influence on the result.

[kangaba]

Well then your test is useless :)
The test is unreliable.

Why?



Qt5 uses QPA, Qt4 doesn''t. Hence my guess about xcb being the reason. What I meant is that Qt5 has to load and initialize the xcb plugin whereas Qt4 just makes a direct call to X11.

Look, xcb is a binding library to X11 just like Xlib, but unlike xlib it's more efficient, so please stop the xcb fallacy. Nobody "talks directly to X11", they use either xlib or xcb to talk to X11, clear now? Hence, Qt4 doesn't make "direct calls to X11" it either uses xcb - which is faster cause it uses direct C calls, or xlib which doesn't and is hence slower.




$ ./a -platform xcb
212 ms

$ ./a -platform offscreen
6 ms

Care to continue the discussion about xcb and Qt5?

Seriously? the window doesn't even show up with offscreen (speaking of bad benchmarks).



There is no such thing as KDE5.

Flashnews.. of course! I said this already.



Yes, I have. KDE has nothing to do with it though. Maybe with the only difference that since I'm using other Qt4 apps, Qt libraries are already preloaded into memory but since the pseudo-benchmark is started after the libraries are already loaded, it has no influence on the result.

Let's be serious, ok? We're not benchmarking CPU jiffies here, if you don't know the reason why qt5 is slower don't play the "the world is sophisticated and your benchmark is wrong" card, because it's valid and shows consistent results as I told you, as you yourself have noticed that Qt4 executes in about 50-70ms and qt5 in about 200-250ms, so stop the pseudo-benchmark bafflegab please.

So the question remains - why is qt5 slower than qt4?
Now, I tested qt4 both under KDE4 and under Unity, both take like 50-75ms, while the qt5 example in both cases takes about 225ms, so it's clearly something wrong with qt5, so I'll take this to the qt dev list since nobody seems to know what's the reason and if/when this gets fixed.

[wysota]

Why?
I think Chris and I have told it enough times to not repeat it again.


Look, xcb is a binding library to X11 just like Xlib, but unlike xlib it's more efficient, so please stop the xcb fallacy.
xcb also happens to be a Qt platform plugin using libxcb to talk to the X server (and do a bunch of other stuff). Whether it is more efficient or less efficient is completely irrelevant here as the only thing QApplication constructor does related to the X server is to connect to it (and possibly do some other initialization). So xcb might be faster in drawing and stuff like that but it doesn't automatically mean it is faster in initializing.


Nobody "talks directly to X11", they use either xlib or xcb to talk to X11, clear now?
Now you're being picky. What I meant was a call to XOpenDisplay. I don't really care if its done through xlib or any other library. What I care about is that effectively a connection with an X server is established.


Hence, Qt4 doesn't make "direct calls to X11" it either uses xcb - which is faster cause it uses direct C calls, or xlib which doesn't and is hence slower.
I really don't want to continue discussing what I meant by a direct call to X11.


Seriously? the window doesn't even show up with offscreen (speaking of bad benchmarks).
I'm testing QApplication constructor, aren't you? It doesn't create any windows.


Flashnews.. of course! I said this already.
Yes (post #1), and then you spoke of KDE5 again (post #9). I can understand you do not know what the relation between Qt and KDE is as I'm assuming Qt is not your area of expertise but if so then please acknowledge that QApplication constructor doesn't care if you are running KDE4, KDE5 or Gnome 2042. It cares about files present in the system and libraries installed. Once you get to actually displaying stuff or using platform integration, it might care but hardly at this point. And even if it would care, it would just adjust itself to the DE, it wouldn't directly call any DE code since it would require to be linked against that code.


if you don't know the reason why qt5 is slower
Sure I do. I can post the results again if you want:

$ ./a -platform xcb
212 ms

$ ./a -platform offscreen
6 ms

The test code:

#include <QTime>
#include <QApplication>
#include <QtDebug>

int main(int argc, char **argv) {
QTime t;
t.start();
QApplication app(argc, argv);
qDebug() << t.elapsed() << "ms";
return 0;
}



don't play the "the world is sophisticated and your benchmark is wrong" card, because it's valid
It's valid to test something but certainly it's not valid to test QApplication() execution time. You didn't rule out your system from the test, didn't make certain the test process will not be preemptied while executing the tested call so the test is neither repeatable nor resistant to external influence. I'm not pretending my test is reliable but considering the change of the QPA plugin shortens execution time ca 50 times, it is quite safe to assume it is the QPA plugin that's responsible for the difference. If the plugin is implemented and where the bottleneck of the plugin is -- it's a different story. You can build Qt4 with QPA enabled and test the xcb plugin in Qt4 against the one in Qt5 if you want. For me it is a safe guess that times are going to be comparable.


since nobody seems to know what's the reason
You're just not accepting the reason. The Qt Platform Plugin (QPA) that uses xcb is responsible for an increased execution time of the QAplication constructor as it has much more to do than the offscreen QPA plugin from Qt5 or the hardwired code path in Qt4.


and if/when this gets fixed.
It's not going to get "fixed" because it is not "broken".

[kangaba]

Neither xlib nor xcb can take nearly that long to initiate, so forget about xcb, ok?

The only useful idea from your post(s) above is QPA - this might be the issue with the startup time, while your comments about preemption are just silly because we're talking about hundreds of ms lost here, not CPU jiffies or some rare environment, mentioning preemption in this benchmark is simply silly.

Of course it's a (performance) regression - the previous version of Qt executed in ~50ms and the new one in ~220ms (as you yourself noticed!) So give me a break, stop implying it's not an issue when it actually is. Why are you trying to deny the obvious as if you were to blame for this startup regression?

[wysota]

Neither xlib nor xcb can take nearly that long to initiate, so forget about xcb, ok?
If it were for me, I could forget about the whole problem as in my opinion this is purely academic discussion -- I really don't care if the application takes 100ms longer to start if then it executes much faster for the next three months it runs.

You can either accept the fact that some initialization code needs to be called or not. There is no point in discussing it further -- I gave you an idea for an experiment how to verify everything I said -- build Qt 4.8 with QPA support which uses xcb instead of xlib and compare it against Qt 4.8 that doesn't use QPA. My prediction is that QPA-enabled flavour of Qt4-xcb will be closer to Qt5-xcb than to Qt4-xlib in terms of startup time.

I'm not blaming libxcb library for anything here -- let's make that clear, as it seems from the very start you are trying to interpret my words as if I were. I'm just saying that a switch from hardcoded Qt4 code path using xlib to a dynamic Qt5 code path using libxcb has the result of the latter taking longer to initialize (as it needs to load the plugin, resolve all its dependencies, create all required platform objects, etc.). It doesn't automatically mean something is "broken". Simply in order to make many things better, something needed to be made worse. It's not a regression, it's a total architecture redefinition.

And to be honest the only silly thing in this thread was trying to compare Gtk::Application to QApplication. Comparing GTK to Qt is like comparing apples to oranges. Comparing one class from GTK with another similarily called class from Qt is like comparing dinosaures to bananas.

And before you start arguing, here are two quotes (underlines mine):

GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces.

Qt is a cross-platform application and UI framework

[kangaba]

I know Qt and Gtk are apples and elephants and gorillas - that's not the point, and you know it, what I mean is that while moving to Qt5 from Gtk3 I noticed that a simple empty GUI window starts up a lot slower (especially a cold startup is embaracingly slow for an empty window) in Qt5 than in Gtk3. And it is a problem because Qt isn't meant only for big sophisticated apps (like Qt Creator) or middle size apps, it's also meant for little apps like weather, calculator, simple text editor - these should start in a blink of an eye - and having to lose here between ~150ms (warm) to like ~500ms (cold) just by moving from Qt4 to Qt5 is a big loss. If the guys at Qt responsible for performance issues (if there are any) don't see this as an issue they're clearly incompetent, or hypocrites (many companies sometimes try to confuse the client into thinking that a problem isn't really a problem, like back in the days when Java was a lot slower (didn't have a JIT compiler) Sun used to say (lie) that "speed doesn't matter").

Anyway I posted a question on this issue on the qt dev mailing list and awaiting for comments/replies there, since it's weekend I might not get any answers, at all.

[wysota]

I know Qt and Gtk are apples and elephants and gorillas - that's not the point, and you know it,
Lots of things you raise up suddenly happen to "be not the point" :)

Don't move from Qt4 to Qt5 "just because you can". If Qt5 doesn't offer anything you need that Qt4 doesn't offer, stay with Qt4. Currently the only two practical reasons one might want to move from Qt4 to Qt5 are QtQuick2 and C++11.

[kangaba]

"to be the point" - you were just picky, trying to find a strawman all along this thread, the logical fallacy about gtk not being qt one of them or how the benchmark is wrong or whatever else you could come up with.

Those are the only 2 reasons for you.
For me it's not having to learn the diff between v 4 & 5 later on, qt 5+ is gonna be fully compatible with Wayland unlike Qt4, a new OpenGL stack - the GL module is deprecated, so please don't patronizingly tell me what to do and when to move because it's not like you know better than me what I need, ok? As far as I'm concerned you just wasted my time here trying to find a strawman by e.g. telling me that the slower startup is not an issue at all so, as you said, if it's not broken don't fix it - and other logical fallacies I could do without.

[wysota]

qt 5+ is gonna be fully compatible with Wayland unlike Qt4
With Wayland you will have totally different startup times thus making this whole discussion pointless.


a new OpenGL stack - the GL module is deprecated
"Deprecated" means it will not be further developed and not that you shouldn't use it. There are still a number of use cases where using it is preferred over the QOpenGL* interface from QtGui in Qt5. But putting that aside -- please read what I said -- don't switch to Qt5 unless it offers something Qt4 doesn't offer. Being able to use VAO and more types of shaders is something that Qt5 offers which Qt4 doesn't -- if you need it, then use it.


it's not like you know better than me what I need, ok?
What gave you the impression I thought I knew better what you needed? The whole point of this thread is QApplication startup time which seems to be crucial for you thus I'm suggesting a solution to obtain what you told us was important for you.


As far as I'm concerned you just wasted my time here trying to find a strawman by e.g. telling me that the slower startup is not an issue at all so, as you said, if it's not broken don't fix it - and other logical fallacies I could do without.
I wish you to get more satisfactory answers from the mailing list. I just hope the time here wasn't as wasted as you think and that at least you didn't start the thread on the mailing list with "hey, QApplication takes longer to start than Gtk::Application!". Good luck with your endeavours!

[anda_skoa]

See https://codereview.qt-project.org/#change,60248

Cheers,
_