[Webkit-unassigned] [Bug 37292] http://trac.webkit.org/changeset/57215 caused perf/memory regressions

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=37292





--- Comment #4 from Ojan Vafai <ojan at chromium.org>  2010-04-09 10:35:03 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > Would you be open to an experiment where we
> > commit a change putting just that behind a flag or comment that code out? It's
> > hard to get definitive answers testing this locally. Need to actually see it
> > run on the bot to have confidence in the results.
> 
> Given the magnitude of the regression on the specific test, I expect that you
> should be able to get a good qualitative result from testing locally.

I'm looking into this today. I'm also trying to find the specific pages in
those page cyclers that are slowed down. Overall though, running these tests
takes a long time and I have to run them many times to get numbers I have
confidence in. It will take at least most of today.

I am not comfortable leaving a regression like this in the tree for long. Other
perf regressions or improvements happen and it quickly becomes difficult to
judge whether the fixes for the regression actually fully fixed it. My
understanding is that WebKit has a strict no-regressions policy for PLT (am I
wrong?). It seems like that should extend to cases like this.

Is there something we can do in the interim while we figure out how to fix the
regression? The simplest solutions are to put this behind a flag or to
rollback. I'd obviously prefer an option that didn't require one of those two,
but nothing comes to mind that doesn't require getting more data and working on
fixes, which seems like it will take days at least.

Anyways, I'll try to have some useful data ASAP.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.