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 mailing list