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

[Phil Bouchard]

On 07/23/2017 02:48 PM, Thiago Macieira wrote:
> On Sunday, 23 July 2017 11:01:00 PDT Phil Bouchard wrote:
>>> 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.
>
> Did you stop the email client? Did you close the browser? Maybe stopped the
> window manager too? You should also disconnect from the network, in case some
> packets arrive at the wrong time, disable turbo boost, lock the CPU into
> performance mode and disable all but one CPU.

Or 'renice' the process to a higher priority after having killed the 
browser at least. I can try later but Linux is pretty good at optimizing 
processes that are run multiple times so I don't think it'll make a huge 
difference.

>>> 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-compe
>> te-with-more-than-2-GB-RAM-of-Android-phones/answers/7061202
>
> That's not "documentation". It's not comparing apples to apples: it's
> comparing two different applications, written for two different OSes, with two
> different frameworks and in two different languages. There's more than just
> the GC at work here.
>
> And did you read the link you posted? It's saying that with enough RAM, the
> impact of GC is small enough to be ignored.

Yes but when you have more simultaneous apps running then they will 
consume more RAM thus the exact same problem will occur.

>>>> 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.
>
> The developers in question here are not the application writers, but the
> framework developers. You're assuming they/you won't make mistakes and that is
> not a valid assumption to make.

What matters is what is presented to the client and if they can use 
something less error-prone then the faster the apps are going to get 
created so it's a win-win situation.

>> 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!
>
> Are you comparing that to the precompiled QML?

Yes.