Hi m-f-d,
I'd like to solicit feedback about Bug 976216.
I've posted patches to do what I think should happen in that ticket; the
commit comment in the second patch explains the state of the code right now:
"""
The startup cache is invalidated when the buildid changes; see [1] for
details. For MOZILLA_OFFICIAL builds, the buildid is always bumped, so
the startup cache is always fresh on a package re-deploy to device.
Most developers re-deploy using |mach build mobile/android && mach
package && mach install| or similar. This does not bump the buildid.
The re-deployed package will read the out-dated startup cache, leading
to frustrating inconsistencies when developing Javascript, especially
chrome content and module JSMs.
"""
The changes I propose do the following:
"""
This change purges the startup caches every time Gecko is started in
developer builds. This keeps the running Javascript consistent (which
is good for development), but incurs a startup performance
penalty (since the cache must be purged, and since the cached files must
be recompiled, etc).
"""
I argue this performance regression is reasonable, because developer
builds should not be used for profiling performance in general; but this
is where folks might have different opinions.
Your thoughts, please?
Yours,
Nick
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=976216
PS. This is motivated by some experimental work that re-packages and
re-deploys the chrome and Javascript omni.ja resources from within
Eclipse. It's nice! I go from running Fennec to running
Fennec-with-updated-JS Fennec in about 15s. This is a moral successor
to the Fennec Bootstrapper of [2].
[2]
https://mail.mozilla.org/pipermail/mobile-firefox-dev/2013-April/000035.html
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
