On Sat, Jun 20, 2015 at 10:01 PM, Gregory Szorc <gsz...@mozilla.com> wrote:
> > > > On Jun 20, 2015, at 20:55, Mike Hommey <m...@glandium.org> wrote: > > > >> On Sat, Jun 20, 2015 at 02:36:26PM -0600, Aaron Klotz wrote: > >>> On 6/20/2015 10:20 AM, Philip Chee wrote: > >>> Anyone want to try the same with Firefox nightly? > >> > >> > >> Already did it and subsequently filed bug 873638. We can do it if we > modify > >> the encoding of the JS source at omnijar build time. > >> > >> I did some measurements last year at the 2014 JS workweek and it turns > out > >> that the cost of converting the omnijar's JS source to jschars during > >> parsing is equivalent to the benefits we gain from StartupCache. > Assuming > >> that nothing has changed in SM with respect to the time required to do > the > >> conversion, if we eliminate that conversion step, we can eliminate > >> XDR-encoded JS from the StartupCache. > > > > Would encoding the js files in UTF-16 eliminate the conversion step? If > > so, we can easily do that at packaging time, although local builds would > > not benefit from that. > > We could have local builds install a re-encoded file instead of doing a > simple copy/preprocess/symlink. Might add overhead to builds and break some > workflows where people rely on symlinks to avoid rebuilds though. I argue > most JS developers don't care about startupcache most of the time. So no > net win? > On Android, every developer build (roughly, !MOZILLA_OFFICIAL) purges the startup cache every time Gecko is started. See [1]. It avoids understanding a chain of delicate dependencies from the build ID and makes everyone's life easier. It has bitten developers trying to profile start-up time -- we warn loudly in the logcat but it's easy to miss. Nick [1] https://wiki.mozilla.org/Mobile/Fennec/Android#Invalidate_the_JavaScript_startup_cache _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
