Very slow startup by the first run

Hi, I am writing a qt app for an embedded linux platform based on Freescale 5121 PPC core. The Qt version I am using is 4.7.2 static compiled.
The system boots over network and mounts a rootfs over nfs.

I made the following tests:
A small gui app showing only a couple of colored boxes takes over 20 secs to start by the first call. Wenn I quit the app and start it again, it starts instantly.

My first thought was the long load time over nfs (the staticly linked app is about 11 Megs), so I then copied the app into /tmp, which is mounted as tmpfs, meaning almost no load delays. This also didn't change the above behaviour.

Switching to dynamic linking didn't help.

Then I wrote the following app:

Code:

---

int main(....)
{
   QCoreApplication a(argc,argv);
   qDebug() << "test";
   return a.exec();
}

---

this code ( resulting in about 2 Megs) did also show almost the same behaviour, except the delay was about 15 secs.

the apps are all release versions with -O2 compiled

a pure "C" HelloWorld programm with printf does start always instantly.

Any ideas, what to optimize/change or where to begin looking for the bottlenecks?

Are you using release Qt libs as well?

The first 2 apps (gui and qDebug) use qt libs. Both staticly linked. But I also tried with dynamic linked qt libs too.

To find out if the delay was Qt related, I wrote also a small "pure C" without Qt, which doesn't show this behaviour.

You didn't answered my question.
The Qt libs you use are they release or debug versions?

release versions

Qt probably generates a plugin cache or something like that on the first load. Or it might not be Qt's fault after all but rather the linker's.

Quote:

---

Originally Posted by wysota

Qt probably generates a plugin cache or something like that on the first load. Or it might not be Qt's fault after all but rather the linker's.

---

First I thought about these possibilities too, but at configuration level before compiling Qt, all plugins are deselected (image libs such as gif/jpeg/png, sql-related plugins, directfb an co...). Only Linux Framebuffer is as "built-in" selected.

Regarding linker, thats why I also tested with a pure C "hello world", which runs very well. Also on another target with the same CPU-platform, we use framebuffer to show video with linux media interface (V4L2), where everything starts in 4 secs (including u-boot, kernel and canbus).

We get into these first-start-delay problems only when qt is involved...

Quote:

---

Originally Posted by denizlitr

First I thought about these possibilities too, but at configuration level before compiling Qt, all plugins are deselected (image libs such as gif/jpeg/png, sql-related plugins, directfb an co...). Only Linux Framebuffer is as "built-in" selected.

---

Nevertheless the cache is built.

Quote:

---

Regarding linker, thats why I also tested with a pure C "hello world", which runs very well.

---

A pure C hello world doesn't link to all those libraries a full blown Qt app does.

Quote:

---

We get into these first-start-delay problems only when qt is involved...

---

I can only suggest to profile the app and see where the delays occur.

I began debugging the different phases of a test programm, which does show only a window with a red rectangle in the middle. The programm is normally startet with the commandline:

/bin/test -qws -display LinuxFB

which takes about 25 secs to show this rect.

I changed the main(..) to this:

Code:

---

int main(....)
{
printf("Begin qapp\n"); 
QApplication a(argc,argv);
 
printf("Begin mainwindow\n");
MyMainWindow w;
 
printf("Begin qdebug\n");
qDebug() << "test";
 
printf("Begin mainwindow show\n");
w.show();
 
printf("End Init\n");
 
return a.exec();
}

---

I start the app with
$> LD_DEBUG=all /bin/colortest -qws -display LinuxFB

and I see that the longest delay (about 90 % of the startup time) ocuurs at the init of QApplication (the construction of the qapp object).

Any ideas how I can find the, what causes the delay in this constructor ?

You can profile the application as already suggested. Also test your app against an already running qws.

Quote:

---

Originally Posted by wysota

You can profile the application as already suggested. Also test your app against an already running qws.

---

Any application linked with qt starts very slow. In this case starting a qws app would take very long, even if the second app would start fast, meaning the whole system is ready still after a long time. On the other side, I observed that a console qt-application inheriting from qcoreapplication, which doesn't need qws, takes about 15 secs, still veeeery long.

I found that at startup, most of the time is consumed during instantiating QApplication/QCoreApplication. Now I am going to add some printfs with time outputs in the source of Qt to find what takes soo long.

What I don't get, is, why the app starts on the second try almost instantly. The whole app is linked static (except libc and co.). So as you said the qapp must be building something wenn first called, and that is in cache by the second call...

I already told you -- at the first run the plugin cache is built. Maybe something causes it to execute so long.

Hi,

I,m experiencing the same problem while running a Qt app on Atmel board with ARM processor running embedded Linux 2.6.31
Anything new about this?

Qt probably generates a plugin cache or something like that on the first load. Or it might not be Qt's fault after all but rather the linker's.

To find out if the delay was Qt related, I wrote also a small "pure C" without Qt, which doesn't show this behaviour.