A point of reference
R Kent James
kent at caspia.com
Wed Mar 7 18:34:44 UTC 2018
On 3/7/2018 10:16 AM, Ben Bucksch wrote:
> Many tests show that the JS engine itself is very fast and on par with
> C code, so blanket statements are not helpful.
I've commented on this earlier, but the recent experience of real-world
implementations in Thunderbird has been that JS implementations are an
order of magnitude slower than their C++ equivalents, so we implemented
C++ objects in core Thunderbird for Lightning (and have discussed doing
that for Enigmail) to get around this issue. I've also pointed to many
examples of serious Electron users who are resorting to binary objects
due to performance issues.
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.
It would be interesting for someone to take a real-world case, say the
ical implementation, and understand why the JS implementation is slow.
(As an aside, the motivation for JsAccount is orthogonal to these
performance issues. Rather in that case the binary inclusion in
Thunderbird was because the underlying design of account objects in
Thunderbird relies on extendible C++ classes, so JsAccount allows that
extendibility in JS as well.)
More information about the tb-planning