Mark Banner (:standard8) Reporter
	Description • 18 years ago

When we switched from SeaMonkey to being an XUL app (xpfe->toolkit), the Ts numbers regressed:

Linux: 7264ms to 12837ms -> 76% increase
Windows: 656ms to 781ms -> 20% increase

Ideas for Possible causes:

1) SeaMonkey Tinderboxes are still trying to call regxpcom rather than "./seamonkey -register" at the start of the test process (http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/tools/tinderbox/build-seamonkey-util.pl&rev=1.358&mark=1968-1980#1963)
2) We've still got some bits using installed-chrome.txt (see bug 366673)
3) xpfe to toolkit transition.
4) extensions
5) startup handlers

Of these, the first seems the most significant, though I'd have only expected that to affect the first time the app is started. However, it should be easy to fix and try.

Item 2 is also a possibility if that's causing extra restarts/longer processing. I should be able to try it locally, and we could test it out if we fixed 2 files and then temporarily disabled venkman & chatzilla.

The others would require deeper investigation, though 4 is probably unlikely.

I'm happy to drive this, but it'd be useful if others chipped in with ideas (or preferably evidence/fixes).

	Robert Kaiser
	Comment 1 • 18 years ago

I'd expect toolkit's restart at startup to affect us there, but I don't know if tinderbox actually does that.

1) is something we should fix in any case. In other places of tinderbox scripts (profile names, etc.), we detect xpfe-based suite vs. suiterunner due to suiterunner having a non-null vendor name set, I guess we can do that here as well. Note that tinderbox has to work with xpfe-based suite still, as branch tinderboxen run from the same script (branching tinderbox is planned but not done yet).

	Frank Wein [:mcsmurf]
	Comment 2 • 18 years ago

Just as a side note: The Firefox Windows tinderbox sets NO_EM_RESTART=1 (http://lxr.mozilla.org/mozilla/source/tools/tinderbox-configs/firefox/win32/tinder-config.pl#11) to circumvent the problem of tinderbox not being able to kill the app. If we decide to set this variable, this could affect Ts, too.

	Robert Kaiser
	Comment 3 • 18 years ago

OK, I now have an xpfe build and a toolkit build (Linux) from shortly before the switch with jprof enabled, so I can gather some data on them.
I tried to get some data and I'll attach the jprof-generated HTML in the moment, perhaps that can tell us something.

	Robert Kaiser
	Comment 8 • 18 years ago

I for my self don't know a lot what to do with those profiles or how I could get better ones. "realtime" vs. "non-realtime" refers to having JP_REALTIME set or not there. All those tests were done on a 2.4 GHz P4m laptop w/ 512MB RAM - I can hand out tarballs of both builds to someone who has a slower machine to do better tests (and/or who knows better what to do with the results).

	Robert Kaiser
	Comment 9 • 18 years ago

Hrmm, sorry, the build were probably not really fit for good profiling (packaging stripped them, without --enable-debugger-info-modules, etc.) - I'll post new results when I have rebuilt better builds.

	Robert Kaiser
	Comment 11 • 18 years ago

Comment on attachment 267459 [details]
Jprof output: XPFE startup, 1ms resolution, non-realtime

The profile output of the new builds is definately better, but the HTML files are getting too big for Bugzilla to swallow.
I've put the profile output HTML files into http://ctemp.kairo.at/doc/profiles/ now. same applieas as to those above, -rt are those with JP_REALTIME set.

	Mark Banner (:standard8) Reporter
	Comment 12 • 18 years ago

I've got no idea why this has regressed at the moment, and I want to focus on other areas -> reassigning to default owners.

	Mark Banner (:standard8) Reporter
	Comment 13 • 17 years ago

We've just been given a new reference tinderbox on Linux, and this one has Ts down at ~650ms. We're not going to be able to play around with the old one, the guess is that it could be some kind of linking/library issue.

It is also way better than the old value (~7264ms) anyway, which also suggests the previous Linux tinderbox was not quite right.

Not sure if we want to do anything about the windows issues, but we don't seem to be getting much traction on this bug.

So I propose that we close this bug as WFM or Wontfix. If there are any problems, hopefully these will flush themselves out over time.

	Robert Kaiser
	Comment 14 • 17 years ago

Yes, I guess that's WONTFIX. It's a bit unfortunate, but I think the only thing that can still help us gain there is going static or libxul, which we have bugs for already.