[Development] [BB++] Now is 3.5x faster than Node.JS
Phil Bouchard
philippeb8 at gmail.com
Mon Jul 24 00:13:50 CEST 2017
On 07/23/2017 03:54 PM, Thiago Macieira wrote:
> On Sunday, 23 July 2017 12:27:44 PDT Phil Bouchard wrote:
>>
>> Yes but when you have more simultaneous apps running then they will
>> consume more RAM thus the exact same problem will occur.
>
> A problem that can again be mitigated by adding more RAM. Sometimes it's
> easier/cheaper to just throw hardware at the problem than to rework the
> software to be more efficient.
Well if you use more memory then you're clogging the bus. Regardless
with a GC you're just postponing the problem and sooner or later the GC
will have to kick-in. When that happens the OS is unusable.
> You should always design your hardware based on what you expect to run or
> design your software to run on the hardware that you have. If you mis-design,
> then you'll have problems, clearly (and that's the bane of a lot of embedded
> products).
True but BB++ apps are always going to be 3.5x faster than Javascript.
So if you improve the memory chips, the bus and the CPU then BB++ apps
still will be 3.5x faster.
>>> 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.
>
> This is resting on the assumption of a less error-prone framework, which is
> not a given as you're using a more complex system than what is known to the
> developers. You're also comparing apples to apples: clients may not want this
> new framework, if they already used to JS. They don't want to relearn and
> retrain.
There's not much to learn:
- replace 'var' with 'auto'
- function parameters need to be stated explicitly
- closures must use global variables
And honestly to write an app you already need to know:
- C++
- QML
- Javascript
I am not sure why Javascript was chosen in the first place in QML apps
because all that is really useful is the XMLHttpRequest but all that
stuff could be mimicked with BB++ with a minor learning curve. But if
you were to write professional apps then you need to learn the Facebook
Graph API, Push Notifications, AdMobs, etc. so you can't be that stupid.
> Note the last argument can also be applied to QML vs widgets.
>
>>>> 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.
>
> So your tool can detect errors in the same application that the QML compiler
> cannot? Can you give us an example?
Yes and I will give you an example later.
> How does your tool deal with runtime code generation via eval() ?
First you need to ask yourself if that function is really used a lot
because I never used it but if it is then you'll have to use it like a C
printf to pass the parameters, embed a compiler and compile it on-demand.
More information about the Development
mailing list