Just making sure I understand correctly: it sounds like you're saying that, with the test-tweak in comment 9 applied, then our recent frame-constructor change (bug 1873649) doesn't impact perf on this testcase anymore (because we're already slow). Is that what you're saying? If so, I agree that this becomes a bit less worrisome and maybe inactionable, given the other bullet points from comment 3. (I guess this is a case where blowing away a structure and rebuilding it lazily (after the test does a zillion incremental updates) turns out to be faster than trying to keep that structure alive and valid with each incremental update. But yeah, that's probably not a use-case that we want to optimize for, since it's more common for sites to make smaller surgical changes and we'd prefer to keep those faster.)
Bug 1901321 Comment 10 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Just making sure I understand correctly: it sounds like you're saying that, with the test-tweak in comment 9 applied, then our recent frame-constructor change (bug 1873649) doesn't impact perf on this testcase anymore (because we're already "slow" on that thusly-modified testcase in builds from before bug 1873649). Is that what you're saying? If so, I agree that this becomes a bit less worrisome and maybe inactionable, given the other bullet points from comment 3. (I guess this is a case where blowing away a structure and rebuilding it lazily (after the test does a zillion incremental updates) turns out to be faster than trying to keep that structure alive and valid with each incremental update. But yeah, that's probably not a use-case that we want to optimize for, since it's more common for sites to make smaller surgical changes and we'd prefer to keep those faster.)