Hi All, During today's meeting I gave an overview of how we're looking to tackle layout performance work in H2. Here are the quick highlights for posterity and for those who weren't there. CCing a few folks who may be interested.
Goal: We want to focus on work that materially improves product quality. This means measurable wins on sites we care about. We should build a set of high-value and actionable work items, prioritize them, and work on the most high-priority items (rather than having developers just work on the next thing on their minds). Resourcing: Chris Pearce and Daniel Glastonbury will be working full time on performance in H2. We will also pull in other engineers as needed, especially where they have applicable domain expertise (several other people are already working on perf bugs). Performance is a top-line priority for layout, alongside webcompat/feature work, so we will invest in it heavily. Work Items: I filed the layout-perf metabug which will track the set of concrete layout work items. We will work with the Product team to prioritize these against each other. Dependencies should be impactful and clearly actionable. Items that need more thinking or investigation will be tracked elsewhere until they meet the criteria (location TBD). Sourcing for Work Items: * QF: The Firefox-wide Quantum Flow effort is the primary funnel of general performance issues in the product, and will feed us work items for layout. They want help with prioritization and commitments to fix certain bugs in certain releases, so we'll need to work with them to deliver that. * Investigative: Quantum Flow is good at identifying testcases where we're obviously doing too much work, but less good for identifying opportunities to micro-optimize known bottlenecks. So we'll also want to do some profiling on a set of top sites from the product team. They've given us a list, though no guidance yet for dynamic workflows (we may want to ask for this). Reflow and Frame Construction are good things to look at optimizing for these sites, since much of the optimization in recent years has focused on the style system. We should also profile these sites mobile. * Misc: There are various proposed performance items spread throughout the planning docs and under certain bugzilla metabugs (like FastReflows). We'll go through these, investigate, and prioritize. Testing/Measurement: * TP6: The A-Team is working this quarter to stand up deeper metrics for tp6, to measure more points in the page timeline beyond first-non-blank-paint. They'll be working next quarter to expand the set of tp6 sites from five to ~30. * Regression Tests: We should aim to add regression tests for the performance work we do, especially for work that does not impact any existing metrics on Talos. perf-reftests, perf-reftest-singletons, and mochitests (checking layout counters) are all possible avenues for this. * Telemetry: We should make use of Telemetry where appropriate. This can be used to verify and intended impact, but also to test hypotheses about potentially-difficult optimizations (measuring how much time would be saved if we had optimization X, even if we don't have it yet). Comments/suggestions/feedback welcome. bholley _______________________________________________ dev-tech-layout mailing list dev-tech-layout@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-layout
