A point of reference
eyalroz at technion.ac.il
Wed Mar 7 20:07:23 UTC 2018
Ben, can you name any significant applications written in JS? I don't
C++/native code core and JS for plugins/glue code like Mozilla has.) Can
you be specific about the application whose conversion from C++ to JS
you had led, as an example?
Maybe JS is fast enough like you suggest; still, that's a weird argument
you're making about the "10 to 1" when many people (like me) have not
heard about any one of these 10.
I would also be interested to see some robust performance comparisons
between JS and native versions of certain libraries to be able to
asssess this claim of similar performance to native code.
On 07/03/18 20:31, Ben Bucksch wrote:
> R Kent James wrote on 07.03.18 19:34:
>> I have not attempted myself to profile why this is true, but with all
>> of these real-world examples of problems with serious attempts at
>> JS-only implementations, you need to question the blanket statement
>> "the JS engine itself is very fast and on par with C code". That is
>> the assumption we have made for years, but experience has shown us
>> that it is not that easy.
> Before making drastic architectural decisions, we should investigate
> *why* things are slow.
> For every app changing from JS to C++, there are 10 apps that change
> from C++ to JS.
> I've myself led efforts of applications that were C++ being rewritten in
> JS, and the result in JS was fast. And much nicer :-). That application
> had 5 million users. The old C++ version had only 1 million users, which
> shows that the JS re-implementation was a success.
> I suspect that there is a common mistake in *how* JS is being used. For
> many JS-driven websites, it's pretty clear why they are slow - bad
> engineering, e.g. linking several MB of JS library code. We need to find
> the issue and fix/avoid it.
> tb-planning mailing list
> tb-planning at mozilla.org
More information about the tb-planning