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
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 interface
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
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 pulse
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
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 ca
14 matches
Mail list logo