I forgot the mention. The only real change between this and the CL Ray
reviewed was that I added a no-op dependency recorder in the unit test.
On Mon, Jun 11, 2012 at 5:23 PM, skybr...@google.com wrote:
I don't understand this code, but I wonder if there is any way to write
a smoke test for
For the record:
https://bugzilla.mozilla.org/show_bug.cgi?id=726790
They are not interested in fixing anything pre FF40.
-Alan
On Mon, Feb 13, 2012 at 5:00 PM, Chris Conroy con...@google.com wrote:
LGTM
On Mon, Feb 13, 2012 at 5:55 PM, acle...@google.com wrote:
On 2012/02/13 22:41:01,
Hey Ray, how do you feel about the CL at a higher level?
I'd like to check this in sometimes this week so internal teams can
experiment with it.
This should not break anyone who doesn't have -XfragmentMerge anyways.
-Alan
On Wed, Jan 25, 2012 at 4:00 PM, acle...@google.com wrote:
Reviewers:
Brian and Ray has been experimenting with different approaches to debug dev
mode that steer away from browser plugins / APIs. They have had some
success but from what I understand it is still in a very early stage.
My plan is to keep FF going as long as possible in the mean time.
-Alan
On
I don't really understand this point. Smaller fragments are still strongly
cachable - there are just more download requests, no? In a multi-page app
it is likely that most of the code in the left overs fragment (used in other
pages) will not be needed.
What Lex described was having N
, Alan Leung is working on this for the
next release, it just means it has to be done with heuristics, and it
takes time to get those right. Basically, you can make a graph,
where each vertex is a split point, and each edge between vertices
represents a shared fragment of code that is alive
