Re: JSBC: JavaScript Start-up Bytecode Cache

2017-06-13 Thread Boris Zbarsky
On 6/13/17 5:23 PM, Kris Maglione wrote: Yes and no. We do something similar to this for the module loader and subscript loader, but only for the entire compiled source, not for individual functions, and without any kind of lazy compilation. True. For

Changing .idl files

2017-06-13 Thread Nicholas Nethercote
Hi, What must be considered when changing an XPIDL interface in a .idl file? As far as I know, it's the following. (1) Update browser C++ code that uses the interface. This is easy because the compiler will tell you the parts that need changing. (2) Update browser JS code that uses the

Re: JSBC: JavaScript Start-up Bytecode Cache

2017-06-13 Thread Mike Hommey
On Tue, Jun 13, 2017 at 12:10:58PM -0400, Boris Zbarsky wrote: > On 6/13/17 11:00 AM, Dirkjan Ochtman wrote: > > Has anyone thought about doing similar things for chrome JS? > > We've been doing fastload for chrome JS (and indeed for entire chrome XUL > documents, including their scripts) for 15+

Re: JSBC: JavaScript Start-up Bytecode Cache

2017-06-13 Thread William Lachance
On 2017-06-13 4:36 PM, Chris Peterson wrote: Nicolas, when JSBC is enabled by default, should we change our test procedure for our various page load tests (Talos and Softvision's manual testing)? Since the first page load will be slower than subsequent page loads (as you noted in the bug [1]),

Re: JSBC: JavaScript Start-up Bytecode Cache

2017-06-13 Thread Chris Peterson
Nicolas, when JSBC is enabled by default, should we change our test procedure for our various page load tests (Talos and Softvision's manual testing)? Since the first page load will be slower than subsequent page loads (as you noted in the bug [1]), should we throw away the first page load

Re: Rationalising Linux audio backend support

2017-06-13 Thread wrzlbrmbft559
I know, it's a pretty late answer but: My four Computers, running on Linux (OpenSuSE) are working fine with alsa from the beginning of alsa on. Now there is no need for a unneccessary intermediate layer named Pulseaudio in an fine working alsa-system. Numberless Tux-Users ignore pulse and

Re: JSBC: JavaScript Start-up Bytecode Cache

2017-06-13 Thread Nicolas B. Pierron
On 06/13/2017 03:59 PM, David Teller wrote: On 6/13/17 5:37 PM, Nicolas B. Pierron wrote: Also, the chrome files are stored in the jar file (If I recall correctly), and we might want to generate the bytecode ahead of time, such that users don't have to go through the encoding-phase. How

Re: JSBC: JavaScript Start-up Bytecode Cache

2017-06-13 Thread Boris Zbarsky
On 6/13/17 11:00 AM, Dirkjan Ochtman wrote: Has anyone thought about doing similar things for chrome JS? We've been doing fastload for chrome JS (and indeed for entire chrome XUL documents, including their scripts) for 15+ years now, no? -Boris

Re: JSBC: JavaScript Start-up Bytecode Cache

2017-06-13 Thread David Teller
On 6/13/17 5:37 PM, Nicolas B. Pierron wrote: > Also, the chrome files are stored in the jar file (If I recall > correctly), and we might want to generate the bytecode ahead of time, > such that users don't have to go through the encoding-phase. How large is the bytecode? I suspect that if

Re: JSBC: JavaScript Start-up Bytecode Cache

2017-06-13 Thread Nicolas B. Pierron
On 06/13/2017 03:00 PM, Dirkjan Ochtman wrote: On Jun 13, 2017 11:55, "Nicolas B. Pierron" wrote: The JavaScript Start-up Bytecode Cache⁰ is a project which aims at reducing the page load time by recording the bytecode generated during the last visits and by-pass

Re: JSBC: JavaScript Start-up Bytecode Cache

2017-06-13 Thread Dirkjan Ochtman
On Jun 13, 2017 11:55, "Nicolas B. Pierron" wrote: The JavaScript Start-up Bytecode Cache⁰ is a project which aims at reducing the page load time by recording the bytecode generated during the last visits and by-pass the JavaScript parser. So this is about

Re: JSBC: JavaScript Start-up Bytecode Cache

2017-06-13 Thread Ben Kelly
On Tue, Jun 13, 2017 at 5:50 AM, Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > The JavaScript Start-up Bytecode Cache⁰ is a project which aims at > reducing the page load time by recording the bytecode generated during the > last visits and by-pass the JavaScript parser. > > This

JSBC: JavaScript Start-up Bytecode Cache

2017-06-13 Thread Nicolas B. Pierron
The JavaScript Start-up Bytecode Cache⁰ is a project which aims at reducing the page load time by recording the bytecode generated during the last visits and by-pass the JavaScript parser. This project changes the way we process JavaScript script tags which are fetched from the network, and