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

[Phil Bouchard]

On 07/23/2017 12:53 PM, Thiago Macieira wrote:
> 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.

I am running it on an Intel Core i7 laptop with an ASUS motherboard and 
no I stop processes like the music player before running it.

>> 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.

You can find documentation on this all over the place:
https://www.quora.com/Why-is-the-iPhones-1-GB-RAM-touted-to-be-able-to-compete-with-more-than-2-GB-RAM-of-Android-phones/answers/7061202

>> "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.

Developer won't need to bother about Root.Ptr because I already wrote a 
parser to add the necessary node_proxies and metadata.

And did I say errors are reported at compile-time? In QML/Javascript 
everything is reported at run-time; sometimes in the widget itself, 
sometimes on the console and sometimes none is reported and it just 
doesn't work!