Notes of the branch planning meeting on Friday.
We have some serious regressions on the builds from
late last week we need to get resolve before moving on
to any additional landings and carpools.
chris h.
Chris Hofmann wrote:
things going well. all known landing regressions resolved.
recap and current bug list status...
-mscott mail perf
all landed. 16 bugs on the status summary = [cache] regression list
-gagan,gordon,darin, beard on necko cache
win32 only was turned on as of Friday. Other platforms coming.
-pav,saari on libpr0n
pav to develop cache regression bug list and post. Its started as
a status summary = [libpr0n] bugzilla list.
mscott helping with http://bugzilla.mozilla.org/show_bug.cgi?id=73250
-infinite loop when trying
to read messages with image attachments.
http://bugzilla.mozilla.org/show_bug.cgi?id=67454
need to be checked
to see if can be removed.
phil reports memory use goes to 90MBs on win32
after running jrgm's
pageloader speed test.
darin, pav, and others to investigate
since libr0n is the
first user of the memory cache. Need
a bunch of eyes
on this...
jrgm also reports mixed results on page loading times
where we should
be taking advantage of the cache, but first
time page loads have
regressed posted results to performance news
group. see attached
and bug http://bugzilla.mozilla.org/show_bug.cgi?id=73295
pav has the bug now, but we need others with
checkins from late
last week to look at the problem to eliminate
the possibility of regression
or side effects from other changes for view
manager, necko,
don't repaint dirty rect. http://bugzilla.mozilla.org/show_bug.cgi?id=37779
and any others that might have positive or
negative effect on page
loading times.
-hewitt,blakeross,... - xul reorging
[EMAIL PROTECTED] and blakeross have
other changes with
impact coming. should carpool
and wait until we get the
resent performance and mem use regressions
cleared.
no update...future landings updates
-scc large number of string changes.
branch/build instructions?
experimental build evaluation/testing results?
landing regression bug list?
no update
-bidi - erik
branch/build instructions?
experimental build evaluation/testing results?
landing regression bug list?
no update
-lord javi ddrianan
branch/build instructions?
experimental build evaluation/testing results?
landing regression bug list?
jband might be ready towards the end of 0.9
-jband/jst XPConnect/Dom conversion.
jst to follow jband.
branch is not quite ready for addtional testing help.
Here's the test results for today, reported in the same way as other days, where I'm taking the average of the median reported load time for each URL. In mac comm. verification builds, the new cache is not enabled, but the old cache is not working either (as yesterday), so times for today are about the same overall as yesterday. In the win32 and linux comm. verification builds for today, the new cache is working. With the old cache, by the time we returned to a given page, we had already evicted the images from that page from the cache (due to the 512 entry limit). However, now, a second visit to the same URL will load the images from the cache, and that would be faster than loading them from the network. So, this result is really now reporting the "if-cached" load times for these URLs. The drop in the reported time on win32 is due primarily to the fact that it stops reporting ~20sec times for slashdot, expedia and voodooextreme, dropping the average down by ~1.2 seconds. It also began timing out (never firing onload) for voodooextreme, tomshardward, cnn, and msn. Note: win32 performance when things are "in the cache" is not significantly better than in builds of 3/21 or 3/19. But, it's "initial visit" times are ~30% slower in 3/23 than in 3/21. Bug coming up. Oddly, linux shows the opposite: when things are "in the cache", page load times are about 85% of the "initial visit" in the 3/23 build. Page load times for the "initial visit" are not significantly different in builds of 3/19, 3/21 and 3/23. (pinkerton: what's the greek word for this? Perplexos?)
