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

[Thiago Macieira]

On Sunday, 23 July 2017 07:48:48 PDT Phil Bouchard wrote:
> > * You still did not provide evidence that the problems in your QML
> > application where due to the garbage collection.
> 
> 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.

Are you running this on a multitasking system with other processes and threads 
running? Maybe on a CPU and GPU that can increase and decrease the clock 
speed? Maybe even a CPU that has thermal-limited turbo-boost that periodically 
overclocks the CPU?

If you are, then I think you should consider other sources of 
unpredictability.

My experience with benchmarking very controlled and deterministic C++ code 
(deterministic implies no memory allocation or deallocation) is that the 
results vary on a system like that.

> It's like Google's choice of using Java for the Android just because
> it's popular. But the Android hangs constantly because of the GC that
> runs in the background.

That's another example of assigning blame without proof. You may be completely 
right and you're very likely partially right. But you need to stop blaming GC 
for everything. We don't know how much it's at fault for, not without 
evidence.

> "ARC differs from garbage collection in that there is no background
> process that deallocates the objects asynchronously at runtime. Unlike
> garbage collection, ARC does not handle reference cycles automatically.
> This means that as long as there are "strong" references to an object,
> it will not be deallocated. Strong cross-references can accordingly
> create deadlocks and memory leaks. It is up to the developer to break
> cycles by using weak references."
> 
> https://en.wikipedia.org/wiki/Automatic_Reference_Counting
> 
> It's obvious developers aren't perfect either and the more complex the
> app is then the more likely there will be a leak. With Root.Ptr it's all
> handled implicitly.

Except for the part that developers need to use root.ptr properly. As you've 
just written, developers aren't perfect either, so they will make mistakes. So 
maybe it's better to have a slightly inferior solution performance-wise that 
works in many more cases where the developers are making mistakes than a 
perfect solution that requires perfect developers.

In fact, I do believe we are working on a framework that positions itself 
exactly like that...

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center