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

[Phil Bouchard]

On 12/29/2016 04:14 AM, Simon Hausmann wrote:
> Hi,

Sorry for the delay...

First I would like to point out this popular Javascript test runs 1.5 
faster using Qt over WebKit:

- ~100 FPS on my laptop (x86 @ 2.40GHz) using Chrome (WebKit):
http://www.themaninblue.com/experiment/AnimationBenchmark/html/

- ~150 FPS on my laptop (x86 @ 2.40GHz) using Qt (without QtQuickCompiler):
http://finitetheory.com/personal/phil/JSBenchmark.tar.gz

- I am still waiting for the QtQuickCompiler request to be fulfilled but 
anybody who has it already is welcome to try it out and please let us 
know the results.

Anyway good job Qt, that's a good start!

> I don't doubt that root_ptr can be used at all. What I'm curious about
> is what your thoughts are on how it could perform, how you would map its
> strengths to the allocation patterns of QML binding evaluations and
> general ECMAScript code.

I am guessing you are referring to QML property bindings here which can 
easily be cyclic.  So these properties will easily be detected by the 
destructor of root_ptr:
https://github.com/philippeb8/root_ptr/blob/master/include/boost/smart_ptr/root_ptr.hpp#L426

The idea is to keep one root_ptr per container (or instantiation of an 
object with a list of children) and each property of this object is 
guaranteed to be deleted when the object is destroyed.  So that's the 
main strength and the same goes for entire Javascript pages where its 
memory allocations are guaranteed to vanish on destruction.

Moreover the relation root_ptr (parent pointer) -> node_ptr (children 
pointer) is fine.  There is one drawback in the relation root_ptr -> 
root_ptr where no cyclic detection mechanism is in place.  I believe it 
is possible to add one there but I don't think it is worth the efforts.

Therefore if you have cycles mostly in property bindings then a root_ptr 
per object and node_ptrs for its children will be fine.  The node_ptrs 
can point to other sub objects having a root_ptr each (a child pointer 
can point to a parent).  The rest of the code written in QML is 
structured like a tree as far as I know and no cycles can be present there.

Thus we just need to confirm what I am saying is right; that QML / 
Javascript cycles are present only in property bindings.


Thanks and Happy New Year,
-Phil

> For the record: Any animation code that _doesn't_ use QML Animators does
> indeed run in the same thread as the STW garbage collector and is
> therefore subject to its non-deterministic behavior (from the animation
> PoV). QML Animators on the other hand are run entirely in the render
> thread and are not affected by any pauses in the gui thread, whether it
> is caused by long running scripts, the garbage collector or
> blocking disk I/O. If with today's release you want to have guaranteed
> lag-free animations, then the use of animators over NumberAnimation,
> etc. is required. That is why it _is_ possible to run smooth animations
> with the scene graph and QML on crazy high resolution displays at
> minimal CPU usage.
>
>
> That said, it is our expressed goal to improve the garbage collector to
> interrupt the GUI thread as little as possible, because not everything
> can (and should) be solved with animators. Scrolling in a listview,
> delegate re-use, property re-bindings, etc. are things that still have
> to run in under 16 ms. So without any doubt there is work to do ��
>
>
> Simon
>
> ------------------------------------------------------------------------
> *From:* Development
> <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of
> Phil Bouchard <philippeb8 at gmail.com>
> *Sent:* Wednesday, December 28, 2016 2:44:24 PM
> *To:* development at qt-project.org
> *Subject:* Re: [Development] Proposal for "container-oriented
> deterministic memory manager"
>
> On 12/28/2016 08:36 AM, Simon Hausmann wrote:
>> Hi,
>>
>> building on the suggestion: do you have any thoughts about how your
>> allocator could be used instead of a garbage collector in an ecmascript
>> implementation?
>
> I'll have to look into the details of the ECMAScript but root_ptr can
> handle neural networks so I'm not sure why it should fail with ECMAScripts.
>
> I won't be able to reply during the day today but I can study specific
> cases this week.
>
> _______________________________________________
> 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
>