25.12.2016, 22:35, "Phil Bouchard" <[email protected]>: > On 12/25/2016 02:15 PM, Konstantin Tokarev wrote: >> 25.12.2016, 08:50, "Phil Bouchard" <[email protected]>: >>> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
