[Development] Proposal for "container-oriented deterministic memory manager"
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:
>>>>> 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:
>>>> 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
More information about the Development