Notes from Wednesday, 3/7/01, performance meeting...
Thanks for those who attended.
Comments are welcome!
Updates/status on recent scheduled carpool landings
- scc string changes. test build on Tuesday?
scc test build out on Monday
scc forward build instruction to chofmann
STATUS: scc expect to be done with Unix this afternoon, and also working with mscott to make sure his stuff doesn't impact commercial tree. plan on landing his changes soon. (looks like he has already in the landing process.)
- pavlov libprOn. test build on Wednesday?
pav forward build instruction to chofmann
pav send known bug list to chofmann
STATUS: pavlov is finishing up on his part. has a build from the tip. gotten some test data with his own tree. will be checking in soon.
- necko cache with http and ftp. test build on Thursday?
gordon/darin forward build instruction to chofmann
new cache for imap will come later when mail
performance branch lands
should see some additional bloat in build until switched
over to new cache
STATUS: gagan said that darin is still working to get http working with new cache by Monday. Hope to enable developers to surf with new cache on Monday. Need a week of baking time before turning on for everyone.
Startup issues:
- jrgm has startup measurement tools. Any data to post?
- pre-loading
* look at at pre-loading of code at startup, law, do
you have a bug?
STATUS: cathleen will check with law.
law replied to me and said he had done some investigation last week, see his posting on
news://news.mozilla.org/3A9C06F3.80403%40netscape.com
He also claimed that rickg is going to look at what libraries to preload and/or services to initialized so that the first window opens quickly.
- late-loading
* java/plugins initialize at startup, Joe Chou
(joe.chou@eng.sun.com)
http://bugzilla.mozilla.org/show_bug.cgi?id=26516
STATUS: cathleen will check with Joe Chou at Sun.
* wallet and cookie should be lazy initialized (Steve Morse)
http://bugzilla.mozilla.org/show_bug.cgi?id=14889
STATUS: selmer check with morse on status on bug 14889, to lazy init wallet.
chofmann state that there are about 1/4 of a meg of binary we load between wallet, xpinstall, activation and profile. we all agree that profile is necessary, but we need to check on other components to see if there is more efficient way to init those library.
* late loading JS (Brendan)
http://bugzilla.mozilla.org/show_bug.cgi?id=68045
STATUS: cathleen will check with brendan
* waterson reports PRLoadLibrary takes 4 seconds out of a 16
seconds of startup time on win98, 32MB 200MHz after reboot
and there is about 6 seconds with other disk grinding. Then on
2nd startup, it takes about 6 seconds without the 6 seconds
disk grinding and 4 seconds PRLoadLibrary time.
Bounty of 2dz donuts for finding out what's going on!
STATUS: waterson said that kandrot came up with a possible explanation of why stuff might be slow. Theory is PRLoadLibrary may be fast, it's usually doing a memory map. As we start creating code, stuff gets paged in lately. On the second run, everything is all mapped in. That's why we're seeing the slowness.
Revisiting the pre-loading mozilla idea...
- how is start-up crash going to impact, if we do pre-loading
- understand the nature of the start-up problem users are seeing
user start-up multiple times a day vs. turning on computer 1st time is slow
- figure out pre-loading or load less
- prove kandrot's hypothesis (lots of disk activity due to dll is still
being bought into physical memory as we executing code or read DLL)
- how long it takes for embed shell to start
- are we reading whole bunch of files in poor faction?
selmer to check with rickg regard to where he is at with his pre-loading DLL stuff.
Page Loading
- general
* page loading performance regression needs love!
news://news.mozilla.org/3A81FFD6.1090401@netscape.com
some improvements has been checked into the tree for
http://bugzilla.mozilla.org/show_bug.cgi?id=69534
jrgm reported improvements in win32 (~ 7%) and linux (~10%),
but mac didn't change much, getting results of +/- 2%
STATUS: Marc is the big hero this week!!! :-)
Marc's fix did a major improvement in page load time for win & linux. Need to verify that we also reduce the number of reflow. Theory is it should too.
Pink is going to check with Rod and Simon to find out what's going on with the Mac.
* darin's bug for further adventures in page loading times
http://bugzilla.mozilla.org/show_bug.cgi?id=66516
STATUS: darin is checking in the fix today (wed).
* large table loading is slow...
there appear to be other performance issues uncovered by the
dreaded table torture test.
http://www.mozilla.org/newlayout/testcases/stress/wbtblclr.html
http://bugzilla.mozilla.org/show_bug.cgi?id=67692
http://bugzilla.mozilla.org/show_bug.cgi?id=54542
1) karnaze is to do more investigation with both bugs together.
A link within bug 54542 has indicated that with 4.7 took 1-2 sec
to load, but with mozilla takes 10-15 sec.
2) hyatt also volunteered to help looking in Quantify.
STATUS: karnaze hasn't got time to look into bug 67692, but he is suspecting problem with style system or frame constructions, not with table reflow.
New Issues
* a new cookie performance bug
http://bugzilla.mozilla.org/show_bug.cgi?id=71071
cookie file gets blown away every time we adds a new cookie.
* big concern about hardware impact with our performance testing.
issue: delta on slow machine is much greater than delta on fast machine.
to do: besides CPU speed and memory, we also need to test
with a variations of disk, video and resolution to figure
out what hardware has the greatest impact on mozilla
performance.
cathleen is assigned to talk to lchiang regarding to figuring out
how we can get resources to test on different hardware config.
Thanks!
Cathleen