Performance/Status Meetings/2007-July-18: Difference between revisions
		
		
		
		
		
		Jump to navigation
		Jump to search
		
				
		
		
	
| Line 15: | Line 15: | ||
| ** Better reports for sheriffs to easily spot perf regressions | ** Better reports for sheriffs to easily spot perf regressions | ||
| ** Tracking down specific performance issues | ** Tracking down specific performance issues | ||
| * stats change to track AUS usage by osversion. | * stats change to track AUS usage by osversion. [https://bugzilla.mozilla.org/show_bug.cgi?id=382044 bug#382044]. | ||
| *Priorities for infra: | *Priorities for infra: | ||
Revision as of 16:55, 18 July 2007
Participants
Infrastructure
- Generate reliable, relevant performance data (already underway as talos). Talos status update?
http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaTest
- Areas where help is needed
- Discuss talos cpu usage metric (zach)
- expand the scope of performance testing beyond Ts/Tp/TXUL/TDHMTL
- reduce noise in tests to ~1% (suggested by bz, not started)
- move perf tests to chrome, so we get more reliable results, and can test more than just content
- improve performance reporting and analyses:
- Better reports for sheriffs to easily spot perf regressions
- Tracking down specific performance issues
 
- stats change to track AUS usage by osversion. bug#382044.
- Priorities for infra:
- Generate historical baselines
- General profile data regularly on builds
- Getting the perf numbers more stable
- Developing the graph server to display time spent in each module
 
- New ideas
- Question: How are we tracking perf bugs, specifically, and are we doing this the same way we are triaging security bugs? Can we do it the same way if not? (damon)
 
Agenda
Gecko: Perf discussion
- Perfathon update
- vlad has data
 
- pageload test rewrite (bug 387110)
- since we have a chance at a clean break, we should look at how the composite scores are calculated
- do we still want to ignore the biggest value when computing the mean and stddev? (there is caching and stuff that happens during the first time a page is loaded that ends up beneficially effecting subsequent page loads)
- do we want to more cycle more intelligently?
- e.g. do we want to keep cycling (up to some max) until the stddev drops below some number?
- do we want to try to intelligently throw outliers out?
 
 
- update on timer resolution on windows from Rob Arnold.
- Talos results
- What's it look like for 1.8 -> 1.9?
 
- Todo: verification of test results
- Fonts, valid rendering, etc.
- TODO: Stuart: verify that concerns about talos results are addressed
 
- probe update
- stan taking over mozilla/gecko side of probe work
- will get Sun's dtrace patch as well as xp-probes checked in to new toplevel dir, then work on merging the two
 
- crowder taking spidermonkey side
- will be dtrace only
 
- module owners should let stan know if they have any situations that they'd like to analyze, so that he has more information about how to structure the probe work.
- for example, examining loading from network performance vs. loading from disk
 
- Sun guys will be here on Aug 30 to do a presentation on dtrace, followed by hands-on work with a smaller group of engineers
 
- stan taking over mozilla/gecko side of probe work
Previous weeks
- jrpof tinderbox
- synthetic tests (TODO)
- put specific tests into talos framework
- poach mochitest performance tests
- individual reftest-like items
 
- need to get a bunch of people looking at profiles (TODO)
- take up some of these meetings to sit down and look at profiles
- timer-based profiling is better (vtune/jprof/oprofile/etc., not quantify)
- TODO: vlad to generate profile for next week's meeting
 
- running without Fx chrome
- new pageloader stuff can do this
 
- examining default theme for performance issues
- Tp vs. Tp2
- new pageloader stuff avoids this problem
- Tp2 was flawed in some ways -- one big one is that it loaded pages in an iframe, so initial paint delay was never coming into play, and we were potentially reflowing more thannecessary