[Development] Proposal for "container-oriented deterministic memory manager"

Konstantin Tokarev annulen at yandex.ru
Sun Dec 25 20:15:48 CET 2016



25.12.2016, 08:50, "Phil Bouchard" <philippeb8 at gmail.com>:
> On 12/25/2016 12:25 AM, Konstantin Tokarev wrote:
>>>  Greetings,
>>>
>>>  I am a QML developer and it came to my attention that the animation is
>>>  sluggish because of the internal garbage collector.
>>
>>  Do you have any proofs that GC is to blame here?
>
> My app works fine below a certain threshold but as soon as I reach a
> certain level of complexity, the animation of the app randomly starts
> skipping frames. 

Could you please provide self-contained example of application that invokes pathological GC behavior?

>I know the GC randomly kicks in so it fits the same pattern.

Having 2 randomly repeating events in the system does not necessary mean these events are correlated. You should provide profiling results or at least logs that show GC kicking in during animation.

>
>>>  I know about the
>>>  QtQuickCompiler that could speed up the rendering but it still uses a
>>>  garbage collector.
>>>
>>>  I wrote myself a "container-oriented deterministic memory manager"
>>>  called "root_ptr" that could definitely speed up animation of QML objects:
>>>  https://github.com/philippeb8/root_ptr
>>
>>  Any numbers for "definitely speed up"?
>
> Well as you can see on the aforementioned link, root_ptr is as fast as
> the best usage of shared_ptr but detects cycles and uses the same amount
> of memory per pointer.

Decently implemented GC can be faster than shared_ptr, because reference counting churn is avoided

BTW, FAQ says that VS2015 is required to build your code, so it cannot be integrated into V4 until VS2013 support is dropped.

>
> Furthermore it is "deterministic" so it's not going to randomly slow
> down the animation of your app. Also it is "container-oriented" meaning
> once the "root_ptr" of a container is deleted, all of its child ptrs
> gets instantly deleted, bringing down all potential cycles. So the
> deletion of a Javascript page will not leave any dangling memory block
> behind.
>
> I have talked previously to the WebKit group but their implementation is
> too complex to simply "swap" the memory manager. So I was hoping the
> QtQuickCompiler generates a cleaner memory manager that could be swapped
> relatively easily.
>
>>>  Is that something that could be easily integrated into the
>>>  QtQuickCompiler? If so would there be any interests to integrate root_ptr?
>>>
>>>  Sincerely,
>>>  -Phil
>>>
>>>  _______________________________________________
>>>  Development mailing list
>>>  Development at qt-project.org
>>>  http://lists.qt-project.org/mailman/listinfo/development
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin



More information about the Development mailing list