[Development] QML instantiation performance

[Chris Adams]

Hi Juha,

For some more light on this issue, are you able to run the
qtdeclarative/tests/benchmarks/qml/librarymetrics_performance benchmark on
both 5.1 and 5.3 (you may have to backport to 5.1 as IIRC I made some
changes to the way the components were instantiated for 5.2 before the
benchmark was integrated, but I may be wrong about that.  It was originally
written prior to Qt5.0 release so with some minor changes it will
definitely work against 5.1).

The benchmarks are quite granular, and should allow you to see precisely
which part of the component instantiation is significantly slower.

Kind regards,
Chris Adams.


www.qinetic.com.au - Qt And QML User Experience Specialists

On Wed, Nov 26, 2014 at 6:08 PM, Juha Vuolle <juvuolle at gmail.com> wrote:

> Hello,
>
> apologies for cross-posting. I find this such a fundamental issue that I
> feel
> at least having the best possible understanding of it worth it (if any
> exists, which is also
> a valuable information in itself). I am happy to help if there is
> anything I could check.
>
> thanks,
> Juha
>
> ---
>
> Hello,
>
> I’m having trouble going from Qt 5.1 to 5.3 / 5.4 because of a
> slowdown in QML (15..35% slower).
> This primarily relates to component instantiation and seems quite
> consistent across the platforms and
> QPAs I’ve used recently.
>
> If you have any insights, thoughts or something I could check I would
> highly appreciate them.
>
> I’ve tested on dual & quadcore imx6 (both EGLFS and XCB) embedded
> platform as well as
> few desktop Fedoras. I’ve tested with 5.1.1, 5.3.1 and the latest
> 5.4.0. The slowdown varies
> but is fairly consistently between 15..35 %. Instantiation CPU loads
> do not seem to be particularly high (< 70%).
>
> Running QML profiler seems to make results less predictable. So I made
> a very simple application startup timer
> that checks main() -> QQuickWindow::beforeSynchronizing() ->
> beforeRendering() -> afterRendering() -> frameSwapped().
> Please find my "highly scientific" measurements below. I slowed down
> the CPU to make things more clear on the desktop I’m writing
> this email from. This behaviour is not specific to only application
> startup but later runtime instantiations seem also slower.
>
> I am grateful for any thoughts or things I could check.
>
> Thanks,
> Juha
>
> Qt 5.1.1 low CPU qtquickcontrols gallery example startup:
> 1. onBeforeSynchronizing() for the FIRST time, time it took from main():
> 950
> 2. onBeforeRendering() time it took from beforeSynchronizing: 3
> 3. onAfterRendering() time it took from beforeRendering: 1572
> 4. onFrameSwapped() time it took from afterRendering: 5
> = 2530 ms for first frame swapped.
>
> Qt 5.3.1 low CPU qtquickcontrols gallery example startup:
> 1. onBeforeSynchronizing() for the FIRST time, time it took from main():
> 1843
> 2. onBeforeRendering() time it took from beforeSynchronizing: 364
> 3. onAfterRendering() time it took from beforeRendering: 1039
> 4. onFrameSwapped() time it took from afterRendering: 83
> = 3329 ms for first frame swapped.
>
> Qt 5.1.1 low CPU my application startup:
> 1. onBeforeSynchronizing() for the FIRST time, time it took from main():
> 809
> 2. onBeforeRendering() time it took from beforeSynchronizing: 3
> 3. onAfterRendering() time it took from beforeRendering: 1373
> 4. onFrameSwapped() time it took from afterRendering: 88
> = 2273 ms for the first frame swapped
>
> Qt 5.3.1 low CPU my application startup:
> 1. onBeforeSynchronizing() for the FIRST time, time it took from main():
> 1341
> 2. onBeforeRendering() time it took from beforeSynchronizing: 4
> 3. onAfterRendering() time it took from beforeRendering: 2184
> 4. onFrameSwapped() time it took from afterRendering: 10
> = 3539 ms for the first frame swapped
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20141127/81f39d96/attachment.html>