Bugzilla

It seems [in the comparison we had only very few runs](https://perf.compare/compare-results?baseRev=a3590cf454bc8d44e59090e2dde956723b76ca5d&baseRepo=autoland&newRev=9de0c1db34892663017e0fa3f271e3c97841582e&newRepo=autoland&framework=1), but I triggered more and the regression seems to confirm.

Said this, I assume the [improvements we see with sp3 and other tests](https://bugzilla.mozilla.org/show_bug.cgi?id=1924444#c9) 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();
```

As 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.

It seems [in the comparison we had only very few runs](https://perf.compare/compare-results?baseRev=a3590cf454bc8d44e59090e2dde956723b76ca5d&baseRepo=autoland&newRev=9de0c1db34892663017e0fa3f271e3c97841582e&newRepo=autoland&framework=1), 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](https://bugzilla.mozilla.org/show_bug.cgi?id=1924444#c9) 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.