[Interest] How to prevent large qml forms from hitting javascript stack size?

NIkolai Marchenko enmarantispam at gmail.com
Mon Sep 11 10:00:46 CEST 2023


In fact, the very reason I've been asked to investigate this issue was when
an addition of a Loader with a couple elements into a low level component
has blown the stack limits and made things break. I've quickly realized
that despite the loader being inactive, the number in that line increases
by the amount of ALL instances of that low level component mentioned in the
traversal path regardless of whether they are active, loaded or visible.

On Mon, Sep 11, 2023 at 10:51 AM NIkolai Marchenko <enmarantispam at gmail.com>
wrote:

> > You don't want 775k objects in memory all at the same time.
>
> We don't have them in memory. You don't quite get the problem, there's a
> ton of Components AND Loaders below that form as qml engine traverses it.
> The problem is - it _does not matter_ as the total accumulated object
> count in the line in the original post isn't all _active_ objects. It's
> _all objects on the traversal path_.
> In fact: loaders  ADD objects arriving to that
> scope.alloc(compilationUnit->totalObjectCount()); I've checked. The memory
> isn't allocated on that line seemingly, it just makes sure jsStackTop can
> accommodate all of it and goes on its merry way (without even checking for
> limits it seems)
>
> On Mon, Sep 11, 2023 at 10:47 AM Ulf Hermann <ulf.hermann at qt.io> wrote:
>
>> > 775k objects, the form is split into smaller pieces mentioned as
>> > Components to load when needed, but qml engine traverses it all
>> > completely and reserves full memory seemingly
>>
>> Finally, if you really, really want this, you can patch Qt to produce a
>> QV4::ArrayObject on the JavaScript heap rather than just bumping the
>> stack. Using the JavaScript heap comes with a performance penalty for
>> the normal use case, though. If it's behind a switch that enables it
>> only for insane amounts of objects, I will accept such a thing, though.
>>
>> best regards,
>> Ulf
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20230911/666d2dda/attachment.htm>


More information about the Interest mailing list