Re: Intent to implement: Early, experimental support for application/javascript+binast
This is awesome. I understand that we already do some kind of pre-compile for our chrome code, is there any plan/benefit to switch to this eventually there? On Wed, Apr 18, 2018 at 9:50 AM David Teller wrote: > # Summary > > JavaScript parsing and compilation are performance bottlenecks. The > JavaScript Binary AST is a domain-specific content encoding for > JavaScript, designed to speed up parsing and compilation of JavaScript, > as well as to allow streaming compilation of JavaScript (and possibly > streaming startup interpretation). > > We already get a 30-50% parsing improvement by just switching to this > format, without any streaming code optimization, and we believe that we > can go much further. We wish to implement > `application/javascript+binast` so as to start experiments with partners. > > > # Bug > > Bug 1451344 > > > # Link to standard > > This content encoding is a JS VM technology, with an entry point for > loading in the DOM. > > - DOM level: No proposal yet. > https://github.com/binast/ecmascript-binary-ast/issues/27 > - JS level (high): https://binast.github.io/ecmascript-binary-ast/ > - JS level (low): No proposal yet. > https://binast.github.io/binjs-ref/binjs_io/multipart/index.html#overview > > > # Platform coverage > > All. > > > # Estimated or target release > > For the moment, no target release. We are still in the experimentation > phase. > > > # Preference behind which this will be implemented > > dom.script.enable.application_javascript_binast > > > # Is this feature enabled by default in sandboxed iframes? > > This is just a compression format, should make no change wrt security. > > # DevTools bug > > Bug 1454990 > > > # Do other browser engines implement this? > > Not yet. We are still in the experimentation phase. > > > # web-platform-tests > > No web platform specification yet. > > > # Secure contexts > > Let's restrict this to secure contexts. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Early, experimental support for application/javascript+binast
No plans yet, but it's a good idea. The only reason not to do this (that I can think of) is that we might prefer switching to the Bytecode Cache, which would probably give us even better speed ups. I understand that we can't use the Bytecode Cache for our chrome code yet due to the fact that it uses a very different path in Necko, which is the Source of Truth for the Bytecode Cache, but I may be wrong, and it might be fixable. Cheers, David On 18/04/2018 19:09, Dave Townsend wrote: > This is awesome. I understand that we already do some kind of > pre-compile for our chrome code, is there any plan/benefit to switch to > this eventually there? > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Early, experimental support for application/javascript+binast
On 2018-04-18 19:13, David Teller wrote: No plans yet, but it's a good idea. The only reason not to do this (that I can think of) is that we might prefer switching to the Bytecode Cache, which would probably give us even better speed ups. I understand that we can't use the Bytecode Cache for our chrome code yet due to the fact that it uses a very different path in Necko, which is the Source of Truth for the Bytecode Cache, but I may be wrong, and it might be fixable. ByteCode cache is implemented "natively" only for http:// urls through http channels talking to http cache. There is an effort to implement the alternative-data bits of the caching channel interface (implemented by the http channel now) also for channels handling chrome: and I think resource: urls. There is lately not much progress on that bug(s) to my knowledge, though. -hb- Cheers, David On 18/04/2018 19:09, Dave Townsend wrote: This is awesome. I understand that we already do some kind of pre-compile for our chrome code, is there any plan/benefit to switch to this eventually there? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform smime.p7s Description: S/MIME Cryptographic Signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
