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

[Phil Bouchard]

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.