Re: Startup cache and resource:// urls

[Nicolas B. Pierron]

The concerns that I have is that the start-up cache proved to be
useful in multiple experiments made by 3 different persons, and at
different occasions and for different purposes:
 - Bug 813324 - Compiled JS cache for Firefox
 - Bug 1101386 - Missing bytecode cache causes SpiderMonkey to be 6x
slower than JSC at 2nd (or consecutive) execution of
TypeScript-compiled code
 - Bug 1164389 - Allow certified applications to load XDR bytecode

So these numbers only highlight that using a bytecode cache is better
than not using any, but they do not compare the caching the
jschar-source against bytecode cache, and I would really appreciate to
have this kind of information before doing these changes.
Also note that in the previous tests, the bytecode cache only got used
for caching the full bytecode, while today we are capable of saving a
sparse version of the bytecode which only contains function used
during the last execution, which reduces the bytecode cache size by
30%.

So my concern is, that we are moving away from a system that we do not
use optimally yet.


On Tue, Nov 24, 2015 at 7:42 AM, Aaron Klotz  wrote:
> On 11/23/2015 10:22 PM, Mike Hommey wrote:
>>
>>Can the perf team look into this? Note the startup cache only matters
>>on the first startup for a given build, and that might be a reason why
>>we fail to track its performance impact.
>>
>>
> We can get rid of it if we properly encode JS source in the omnijar. Unless
> something has changed in SpiderMonkey, the last time I looked we convert the
> JS source in the omnijar to jschars at parse time. Eliminating that
> conversion step would cancel out the benefit of the startup cache.
>
> I seem to remember NBP expressing concern with this plan in Whistler.
> Nicolas, do you recall what your concerns were?



-- 
Nicolas B. Pierron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Startup cache and resource:// urls

[Kris Maglione]

On Tue, Nov 24, 2015 at 02:22:44PM +0900, Mike Hommey wrote:

 Note the startup cache only matters
 on the first startup for a given build, and that might be a reason why
 we fail to track its performance impact.


Presumably also when we flush the startup cache for changes in 
add-ons?



 Most code in Firefox itself fortunately uses resource:/// instead of
 resource://app/ (they have the same meaning, or at least were supposed
 to, since the bug broke this promise), so it was fortunately not a
 direct problem for Firefox itself.


I've never seen resource://app/ used in an add-on. Just about 
all of the uses MXR can find[1] are either in Thunderbird 
add-ons, or are appalling hacks like this in themes:


   list-style-image: url("jar:resource://app/omni.jar!/chrome/toolkit/skin/classic/global/tree/twisty-clsd.png"); 


[1] https://mxr.mozilla.org/addons/search?string=resource%3A//app/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Startup cache and resource:// urls

[Mike Hommey]

On Mon, Nov 23, 2015 at 10:26:39PM -0800, Kris Maglione wrote:
> > Most code in Firefox itself fortunately uses resource:/// instead of
> > resource://app/ (they have the same meaning, or at least were supposed
> > to, since the bug broke this promise), so it was fortunately not a
> > direct problem for Firefox itself.
> 
> I've never seen resource://app/ used in an add-on. Just about all of the
> uses MXR can find[1] are either in Thunderbird add-ons, or are appalling
> hacks like this in themes:
> 
>list-style-image: 
> url("jar:resource://app/omni.jar!/chrome/toolkit/skin/classic/global/tree/twisty-clsd.png");

... which seems to be a *very* old thing because:
- resource://app might have pointed to the plain Firefox directory where
  you could find the omnijar a long time ago (I don't remember if that
  ever was actually true), but it points *inside* the omnijar now.
- omni.jar was renamed omni.ja a loong time ago.

Arguably, the interesting test, though, would be addons sources from
before FF38, since presumably addons might have changed to work around
the resource://app brokenness.

> [1] https://mxr.mozilla.org/addons/search?string=resource%3A//app/

Note this url is behind a "AMO Admins - LDAP Login" authentication
(which I probably don't have)

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Startup cache and resource:// urls

[Kris Maglione]

On Tue, Nov 24, 2015 at 04:08:56PM +0900, Mike Hommey wrote:

... which seems to be a *very* old thing because:
- resource://app might have pointed to the plain Firefox directory where
 you could find the omnijar a long time ago (I don't remember if that
 ever was actually true), but it points *inside* the omnijar now.
- omni.jar was renamed omni.ja a loong time ago.


Quite. There are some older ones, though:

list-style-image: url("jar:resource://app/chrome/classic.jar!/skin/classic/browser/Toolbar-small.png") !important; 


And some more recent ones:

list-style-image: url("resource://app/chrome/browser/skin/classic/browser/Toolbar.png") !important; 


[1] https://mxr.mozilla.org/addons/search?string=resource%3A//app/


Note this url is behind a "AMO Admins - LDAP Login" authentication
(which I probably don't have)


Any MoCo or MoFo account should have access by default.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Startup cache and resource:// urls

[Mike Hommey]

On Mon, Nov 23, 2015 at 11:29:05PM -0800, Kris Maglione wrote:
> On Tue, Nov 24, 2015 at 04:08:56PM +0900, Mike Hommey wrote:
> >... which seems to be a *very* old thing because:
> >- resource://app might have pointed to the plain Firefox directory where
> > you could find the omnijar a long time ago (I don't remember if that
> > ever was actually true), but it points *inside* the omnijar now.
> >- omni.jar was renamed omni.ja a loong time ago.
> 
> Quite. There are some older ones, though:
> 
> list-style-image: 
> url("jar:resource://app/chrome/classic.jar!/skin/classic/browser/Toolbar-small.png")
> !important;
> 
> And some more recent ones:
> 
> list-style-image:
> url("resource://app/chrome/browser/skin/classic/browser/Toolbar.png")
> !important;

Note, depending on what those addons are trying to achieve with those,
it can be considered our fault that we don't have stable urls to access
data for themes (or locales, for that matter) that are not the current one.

Also note that the last form is valid but is currently broken.

> >>[1] https://mxr.mozilla.org/addons/search?string=resource%3A//app/
> >
> >Note this url is behind a "AMO Admins - LDAP Login" authentication
> >(which I probably don't have)
> 
> Any MoCo or MoFo account should have access by default.

Oh, it works.

So, if I believe this:
- https://mxr.mozilla.org/addons/source/4891/content/config.js#69
  Vimperator's import command is broken
- 
https://mxr.mozilla.org/addons/source/221523/components/nsIPXLNotificationCenter.js#165
  HTML5 Notifications might be broken
- https://mxr.mozilla.org/addons/source/242697/chrome/content/places.js#36
  https://mxr.mozilla.org/addons/source/242697/chrome/content/qrcode.js#233
  ViewMarks is likely broken

... and I stopped about halfway through the list and didn't look
thoroughly at the skin related things.

So I guess there are "only" probably less than a dozen addons actively
broken, but it might still be worth pushing for an uplift of the fix so
as to get it into 43.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform