Closed Bug 876175 Opened 7 years ago Closed 7 years ago
Fix O(n^2) behavior and other perf issues with ns
SVGGradient Frame::Get Paint Server Pattern
Even after the patch for bug 876157, I'm currently seeing 4% of the samples in nsSVGGradientFrame::GetPaintServerPattern while profiling bug 780762. Looking more closely at this method I see several issues in the general case (which should be even worse than bug 876157's single-color cases): * The initial GetStopCount() call iterates over all the children calling queryFrame on them. * nsSVGGradientFrame::GetStopInformation contain's O(n^2) behavior, since it calls GetStopFrame() for each stop index, and that iterates through the child frames from the start each call, counting frames that query to nsSVGStopFrame until it finds the stop at the required index. * nsSVGGradientFrame::GetStopInformation also uses the webidl method |stopElement->Offset()| to get the stop offset, which involves allocating among other things.
For my profiling of rapidly scrolling the SVG in the testcase in bug bug 876157 on and off-screen for 20 seconds, this patch plus the patch in bug 876157 reduces the samples in nsSVGPaintServerFrame::SetupPaintServer from 9.2% of the profile to 0.7% of the profile. My reason for the "8" in the |nsAutoTArray<nsIFrame*,8>| is because that's the value used in other places in layout for nsAutoTArray<nsIFrame*> that seemed closest to a reasonable number you might expect stops to be under. (The next pre-existing value up is 32.)
Attachment #754163 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.