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

[Thiago Macieira]

On Sunday, 23 July 2017 12:27:44 PDT Phil Bouchard wrote:
> Or 'renice' the process to a higher priority after having killed the
> browser at least.

Not enough.

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

Also not relevant. But you should avoid the disk I/O by moving all the code 
that is loaded into a tmpfs and use LD_BIND_NOW=1.

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

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.

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

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

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?

How does your tool deal with runtime code generation via eval() ?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center