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

Konstantin Tokarev annulen at yandex.ru
Sun Dec 25 21:01:25 CET 2016



25.12.2016, 22:35, "Phil Bouchard" <philippeb8 at gmail.com>:
> On 12/25/2016 02:15 PM, Konstantin Tokarev wrote:
>>  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 cannot share my proprietary code but I'll work on some simple example
> this week. Basically it consists of having a "Flipable" object inside a
> complex Delegate object of a ListView. The Flipable animation skips
> frames and the animation is not smooth.
>
>>>  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'll try to find out how to turn on GC logging.
>
>>>>>   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
>
> A GC might be faster at some point but you're just postponing the
> workload to some other point in time. So benchmarks need to be
> objective. Also a GC needs not use a dedicated thread (which most of
> them use) just to be fair in the benchmark.
>
>>  BTW, FAQ says that VS2015 is required to build your code, so it cannot be integrated into V4 until VS2013 support is dropped.
>
> I am sorry for this but this FAQ was copied from a template and this
> statement is false. It was tested using GCC and portable code is one of
> the mantra of the Boost library.

But does it work with VS2013?

>
> _______________________________________________
> 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