Good news regarding Qt 5.5

Aleix Pol aleixpol at kde.org
Fri May 8 17:17:32 UTC 2015


On Fri, May 8, 2015 at 6:55 PM, Marco Martin <notmart at gmail.com> wrote:
> On Friday 08 May 2015 12:49:45 Simon Hausmann wrote:
>> During the investigation  - we also talked about this on IRC - I noticed
>> that plasma creates a lot of QQmlEngine instances - it seems one per
>> applet. In the light of each instance coming with its own garbage
>> collection heap and its own QML type loader thread, this seems rather
>> heavy. I think that if you can change Plasma to share one QQmlEngine for
>> everything and isolate your objects in different QQmlContext instances
>> instead, then you should be able to save _a lot_ of memory and also get
>> much better performance. I'm mentioning performance because this very bug
>
> I gave a try at sharing an engine at least for the desktop/panel widgets:
> I've managed to make something load, for instance loading the systemtray
> widget in plasmoidviewer seems to work and to be functional .. at the highly
> unscientific memory consumption estimate of top, it says memory usage is
> exactly half :O
> so, if this is a figure that will have some foundation in reality, this is a
> road *definitely* to be taken
>
> But now i've hit a blocker that i'm not sure makes it possible to change it in
> a compatible way:
> It relies on QQmlAbstractUrlInterceptor to change some accessed paths in a way
> that's specific of every different plasma widget.
> so with an engine per applet it was easy: every engine had its own
> QQmlAbstractUrlInterceptor instance.. now that there would be a single global
> interceptor instance, i can't know from within the interceptor what is the
> applet that is trying to access a file (or even from what QQmlContext that
> access was done)
>
> probably could have known that using QQmlAbstractUrlInterceptor was asking for
> troubles,  but... any idea? :)
>
> --
> Marco Martin

I have no idea.
Can you push it into a branch? I'd be interested in looking into this.

Aleix


More information about the Plasma-devel mailing list