[Development] [BB++] Now is 3.5x faster than Node.JS
Thiago Macieira
thiago.macieira at intel.com
Sun Jul 23 18:53:34 CEST 2017
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
More information about the Development
mailing list