[Qt-qml] Any tips or tricks to help with long app startup times?

Artem Marchenko artem.marchenko at gmail.com
Thu Sep 29 15:02:22 CEST 2011

Just a quick check:
If you are using lots of local images, have you made sure that your Image elements has asynchronous property set to true? It may have significant impact on the startup performance.

If I get it correctly synchronous loading of local images doesn't mean just frozen UI while image is being loaded, it also means that all of your images are going to be loaded sequentially, one after another, not in parallel. That could delay UI a lot if you've got many local images to load.

Best regards,

On Sep 28, 2011, at 12:28 AM, Todd Rose wrote:

> Thanks Artem.
> I've tried QML Performance Analyzer and I've gotten it to work against
> the Simulator but this is primarily a Symbian app and our Simulator
> build fakes so much stuff that performance testing in that environment
> isn't really useful.   From my debug tracing I see that 5 seconds is
> spent in the call to declarativeView.setMainQmlFile() and another 2
> seconds in showFullScreen().  I'm not sure what I could do about the
> latter, but I'm reworking the top-level of the UI to use Loaders for
> anything that isn't absolutely necessary for the initial view.  I'm
> hoping that will make a noticeable difference.
> QML WorkerScript might be useful in some other cases, but for us we
> have 3 core ListViews whose delegates all contain 2 or 3 Image
> elements (sometimes more).  We have custom image providers that
> scale/crop/transform/composite these images.  We could perhaps get rid
> of some of that but the UI would suffer a bit.   I think the only
> choice here is to try our best to populate list models as needed and
> live with a few loading delays as the user navigates around the UI.
> On Tue, Sep 27, 2011 at 2:59 PM, Artem Marchenko
> <artem.marchenko at gmail.com> wrote:
>> Hi Todd
>> Have you tried QML Performance Analyzer from the latest Qt Creator? I failed to get meaningful device data from it, but maybe you could spend more time with it and force it to work. Also if desktop performance is comparable even desktop measurements maybe helpful.
>> As for a couple of tricks you could use:
>> 1) On Harmattan if it's one of your platforms you could use QML booster - that could help for something like 0.5-1 sec.
>> 2) Splash screen certainly helps hiding low performance, maybe will make it look some 0.5 sec faster
>> 3) QML Loader for loading the not super necessary stuff only when you need
>> 4) WorkerScript is the only QML native way for multithreading. The problem is you can exchange only simple types with WorkerScripts, no image stuff possible
>> 5) XmlHttpRequest is another possibility for loading data asynchronously, but if I've got you correctly, your problem is not with getting data, but with actual instantiation of images
>> If anything above doesn't help, you'll probably need to restructure your UI significantly. I can hardly believe you need that complex UI at start that it takes whole 7 sec to instantiate. These are just 0.2-0.4KPixels on screen after all.
>> Best regards,
>> Artem.
>> On Sep 27, 2011, at 9:37 PM, Todd Rose wrote:
>>> Thanks for the response Pelle.  I wonder if it would help if I routed
>>> all QML Images through one of our native image providers and marked
>>> them all as asynchronous.  Is the QPixmap cache still used even with
>>> custom native image providers that return QImage?  Just loading the
>>> QML and related images takes 7 seconds in our app.   I will look into
>>> loading only the smallest subset of QML necessary at startup, and
>>> doing the rest of the UI on-demand or on timers...unfortunately we
>>> pretty much need the whole UI available at startup, a splash screen or
>>> progress dialog would look prettier but it doesn't solve the problem.
>>> -Todd
>>> On Tue, Sep 27, 2011 at 11:12 AM, Pelle Johnsen <pelle.johnsen at gmail.com> wrote:
>>>> From my experience QML does generally suffer a bit from slow startup time,
>>>> especially on embedded platforms :S
>>>> In the project I'm working on the 2 main problems we found are:
>>>> 1. Actually creating instances of QML Items. In a large app. there can be
>>>> thousands. This can to some extend be helped by splitting up the app and
>>>> sort of delay/demand loading individual parts, so you get the main UI up as
>>>> fast as possibly
>>>> 2. QML Image uses QPixmap which can only be created in the UI thread, making
>>>> it impossible to load QML in a background thread (not sure if there is some
>>>> changes to this in 4.8). If you are doing custom Ui you probably have lots
>>>> of images, which do take time to load up.
>>>> Also see this forum
>>>> thread: http://developer.qt.nokia.com/forums/viewthread/3144
>>>>  -Pelle
>>>> On Tue, Sep 27, 2011 at 4:58 PM, Todd Rose <teeceeare97 at gmail.com> wrote:
>>>>> We have a relatively large qt-qml application.  The back-end is C++
>>>>> and front-end ui is about 70 or so QML files.  We're currently seeing
>>>>> very long initial startup times (ten seconds or more) and we'd like to
>>>>> know if there's any simple things that we can do to mitigate this.
>>>>> Some of it is in our application domain and we're working on that
>>>>> part, but the actual loading and rendering of the QML is also a quite
>>>>> significant portion of overall initial startup time.  Are there any
>>>>> tricks to make loading and initializing the qt and qtmobility
>>>>> libraries faster?  What about the initial QML file load/parse phase?
>>>>> We have all of our resource files stored in application subdirectories
>>>>> - would packaging them in a qt resource file make any difference here?
>>>>> Thanks in advance,
>>>>> Todd
>>>>> _______________________________________________
>>>>> Qt-qml mailing list
>>>>> Qt-qml at qt.nokia.com
>>>>> http://lists.qt.nokia.com/mailman/listinfo/qt-qml
>>> _______________________________________________
>>> Qt-qml mailing list
>>> Qt-qml at qt.nokia.com
>>> http://lists.qt.nokia.com/mailman/listinfo/qt-qml

More information about the Qt-qml mailing list