1931952 - 6.38% perf_reftest_singletons tiny-traversal-singleton.html (Linux) regression on Wed November 13 2024

Status: RESOLVED WORKSFORME

(Core :: Memory Allocator, defect)

Description

[Treeherder Bug Filer]

Perfherder has detected a talos performance regression from push 9de0c1db34892663017e0fa3f271e3c97841582e. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)
6%	perf_reftest_singletons tiny-traversal-singleton.html	linux1804-64-shippable-qr	e10s fission stylo webrender	942.75 -> 1,002.92

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
6%	tp5o_scroll	macosx1015-64-shippable-qr	e10s fission stylo webrender	1.56 -> 1.46
4%	pdfpaint issue1655r.pdf	macosx1015-64-shippable-qr	e10s fission stylo webrender	212.52 -> 205.06
2%	tart	windows11-64-shippable-qr	e10s fission stylo webrender	1.78 -> 1.74

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the patch(es) may be backed out in accordance with our regression policy.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

You can run all of these tests on try with ./mach try perf --alert 42609

The following documentation link provides more information about this command.

For more information on performance sheriffing please see our FAQ.

If you have any questions, please do not hesitate to reach out to [e-mail].

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1924444

Comment 2

[Jens Stutte [:jstutte]]

It seems in the comparison we had only very few runs, I triggered more and the regression seems to confirm at lower rate and confidence, though.

Said this, I assume the improvements we see with sp3 and other tests thanks to this patch would outweigh this regression in any case.

The test itself is a very synthetic test that adds and removes one DOM attribute on the same element many times:

  perf_start();
  var state = true;
  for (i = 0; i < 100000; ++i) {
    elem.setAttribute("id", state ? "" : "foo");
    state = !state;
    flush_style(elem);
  }
  perf_finish();

If the regression of this specific tests confirms, we might want to look into this a bit more. My assumption would be that we just have one non-full run in our list for the affected size class of the attribute and that any single if counts more than the better algorithm. Or maybe Paul's intuition that it is better to move the list element pointers back into the chunk map (where the previous tree pointers were) might reveal right here.

Triggering profiler runs to see if that reveals anything.

Comment 3

[Jens Stutte [:jstutte]]

(In reply to Jens Stutte [:jstutte] from comment #2)

It seems in the comparison we had only very few runs, I triggered more and the regression seems to confirm at lower rate and confidence, though.

Looking at this again, I think there is no real regression here.