[Development] [BB++] Now is 3.5x faster than Node.JS
Phil Bouchard
philippeb8 at gmail.com
Sun Jul 23 16:48:48 CEST 2017
On 07/23/2017 02:50 AM, Alejandro Exojo wrote:
> On Saturday 22 July 2017 18:51:28 Phil Bouchard wrote:
>> You're probably making a living off memory leaks so it's obvious you get
>> offended but I don't think being a counterproductive manager is good for
>> the Qt company. In fact it's the first time ever I hear about a manager
>> complaining about new technologies that is better and... free.
>
> * 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.
> * You did not realize it was impossible to avoid garbage collection in
> JavaScript, and you had to change your plan from improving the engine
> performance, to add a just invented new language to the design to replace a
> (like it or not) well stablished, popular language.
"Popular" doesn't mean it's better. Have you seen how spaghetti
inheritance is in Javascript?
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.
> * You claimed about Objective C's ARC "This means the Apple OS leaks", again
> without proof, and when the technology is very very similar to the state of
> the art in C++ with weak and shared pointers.
"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.
> * You only have brought to the table an implementation that gives nothing that
> QObject already has.
We're comparing BB++ with Javascript here and Javascript was chosen by
Qt to glue the QML code altogether. Given the similarities of BB++ with
Javascript I am just saying to favorize the former and you will get a
3.5x speed boost.
> So, sorry, but if you feel rejected by the members of this list is because of
> dubious technical quality, not because one is "making a living off memory
> leaks".
It's probably a "if it's not broken don't fix it mentality" but that
doesn't fit with science and R&D. I just wanted to help Qt but I can go
back to the WebKit world because WebAssembly should be mature enough now.
Thanks to everybody except Jake and Oleg (tough guys here).
More information about the Development
mailing list