[Development] [BB++] Now is 3.5x faster than Node.JS

[Robin Burchell]

Hi Phil,

On Sun, Jul 23, 2017, at 04:48 PM, Phil Bouchard wrote:
> All you have to do is create a ListView with images in the ListView 
> Items, scroll the ListView and then you will see the ListView's 
> scrolling speed not being uniform in an unpredictable way. Whatever's 
> unpredictable is caused by the GC.

You didn't give any details about how you measured, or what you were
measuring on, so I gave it a shot -- I'm sorry, but I can't replicate
these results, and even with a highly artificial test case[1] that
scrolls a ListView constantly, I only see one GC run every so often, and
it does not delay for any sort of significant amount of time (on a 2013
mbp, running a slightly old Qt 5.9 snapshot, on OS X):

    [D] default: QV4::MemoryManager::runGC:987 - Marked object in 0 ms.
    [D] default: QV4::MemoryManager::runGC:988 - Sweeped object in 1 ms.
    [D] default: QV4::MemoryManager::runGC:989 - Used memory before GC:
    1095008
    [D] default: QV4::MemoryManager::runGC:990 - Used memory after GC:
    106784
    [D] default: QV4::MemoryManager::runGC:991 - Freed up bytes: 988224
    [D] default: QV4::MemoryManager::runGC:992 - Freed up chunks: 14

Running with QV4_MM_STATS=1 with a newer Qt (dev branch) should also
show you a more precise time (in us, rather than ms), as well as
information about what object types were GC'd.

In my experience, GC is not often the root cause of "janky" interaction
in QML, simply because most of the allocations don't originate from
there, unless you are writing a really high amount of JavaScript, or
very complex bindings. The image content of the Image element for
instance is not allocated through garbage collection.

Much more common sources of performance problems:
* doing too much (overly complex delegates, or bindings) -- creating
objects, and evaluating bindings is expensive
* blocking the main thread elsewhere in the application
* problems with the platform or graphics stack (or their integration
with QtQuick)

Of course, even more often, you get some kind of a combination of the
above...

Anyway: my experience doesn't rule out the possibility of there being a
problem, but so far I am lacking evidence that there is one (a test
case), and I am lacking evidence that garbage collection is the cause of
that problem (investigating that test case with QV4_MM_STATS, and other
tooling).

Please create a bug with a test case (simple enough that it can be run
standalone like mine below) where you see more details on the
performance problem you see, with information about your platform, and
full details about how you measured the results (if you did any such
measurements).

[1]: https://gist.github.com/rburchell/3026d3229d4211f71b947e3f9eee6d9f
-- run with qmlscene, setting QV4_MM_STATS=1 in the environment, to get
information about when the GC runs and what the impact is. Uncomment the
animation & onCompleted hook to scroll automatically (and a lot faster).

-- 
  Robin Burchell
  robin at crimson.no