On 11/08/2017 07:50 PM, dmosed...@mozilla.com wrote:
Does this cache bytecode for about: pages as well? As an example, caching
bytecode for various JS scripts from resource: and chrome: for about:home might
get interesting startup improvements...
I would not expect the JSBC to be used in suc
Does this cache bytecode for about: pages as well? As an example, caching
bytecode for various JS scripts from resource: and chrome: for about:home might
get interesting startup improvements...
Thanks,
Dan
___
dev-platform mailing list
dev-platform@li
On Tue, Jun 13, 2017 at 11:54:17PM -0400, Boris Zbarsky wrote:
On 6/13/17 5:23 PM, Kris Maglione wrote:
For
On 06/13/2017 09:38 PM, Mike Hommey wrote:
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
document
On 06/13/2017 08: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]),
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
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+
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]), sh
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+ years n
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 time
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 larg
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
___
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 it's
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 the JavaScript parser.
So thi
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 content JS only? Has anyone thought ab
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 pr
16 matches
Mail list logo
