Re:A New Bytecode Format for JavaScriptCore
by olliej on Friday June 21, 2019 @04:55PM
(#20246245)
binary-ast doesn't give any significant benefits over JS, potentially a small reduction in size vs standard gzip responses, but I've yet to see compelling evidence binast offers any significant time saving to first execution.
It's important to realize: binary-ast is no more readily executable than plain JS, it is no more trustable than plain JS, and even if they were parsing is not been a significant part of ttfe in JSC in a long time. It's the interpreter codgen that eats up time, and the execution speed difference between AST (which JSC used for a looonng time, and the final builds beat the contemporary bytecode interpreters of other engines when it was replaced). The performance of an AST is so much slower than bytecode interpreter that you require a tiny amount of JS before the cost of codegen+execution beats just execution using the AST.
It's important to realize: binary-ast is no more readily executable than plain JS, it is no more trustable than plain JS, and even if they were parsing is not been a significant part of ttfe in JSC in a long time. It's the interpreter codgen that eats up time, and the execution speed difference between AST (which JSC used for a looonng time, and the final builds beat the contemporary bytecode interpreters of other engines when it was replaced). The performance of an AST is so much slower than bytecode interpreter that you require a tiny amount of JS before the cost of codegen+execution beats just execution using the AST.