Perf regression since Firefox 3.6 with SVG Polyline element

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: hfmanson, Assigned: birtles)

Tracking

({perf, regression, testcase})

Trunk
perf, regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [in-the-wild] [external-report], URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

This HTML page contains elements like <object data="spiro.svg?figuur=Fig1.xml" type="image/svg+xml" align="baseline" width="400" height="400">
</object> The references themselves don't hang, e.g. http://mansoft.nl/spiro/spiro.svg?figuur=Fig1.xml


Reproducible: Always

Steps to Reproduce:
Visit http://mansoft.nl/spiro/spiro.htm
Actual Results:  
Hangs firefox

Expected Results:  
some spirograph pictures. Try with Google Chrome or Opera
(Reporter)

Updated

6 years ago
Summary: This page hangs since firefox 4 (also minefield), firefox 3.16 rendered ok → This page is very slow since firefox 4 (also minefield), firefox 3.16 was much vaster
(Reporter)

Comment 1

6 years ago
Update: When you wait several seconds the pictures appear, thus firefox doesn't really hang but takes a long time for rendering which is a regression
I get a slow script warning for 
Script: http://mansoft.nl/spiro/spiro.js:48

SVG or JS ?
Status: UNCONFIRMED → NEW
Component: General → SVG
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
Keywords: testcase
(Reporter)

Updated

6 years ago
Summary: This page is very slow since firefox 4 (also minefield), firefox 3.16 was much vaster → This page is very slow since firefox 4 (also minefield), firefox 3.16 was much faster
(Reporter)

Comment 3

6 years ago
The problem also occurs on a single SVGs, it seems the problem lies in XMLHttpRequest, e.g. http://www.mansoft.nl/spiro/spiro.svg?figuur=Fig4.xml
(Reporter)

Comment 4

6 years ago
I updated spiro.svg which now shows the problem directly. XMLHttpRequest is not used when no querystring is present. See http://www.mansoft.nl/spiro/spiro.svg
So it is a pure SVG problem, not XMLHttpRequest unlike I stated in Comment 3.
(Reporter)

Updated

6 years ago
Created attachment 523367 [details]
original testcase

Here's the original testcase (with js file merged into SVG file).

Confirming -- this takes ~7 seconds to load in a mozilla-central nightly, whereas it takes less than 1 second to load in Firefox 3.6.16

Mozilla/5.0 (X11; Linux i686; rv:2.2a1pre) Gecko/20110327 Firefox/4.2a1pre
Keywords: regression
OS: Windows Vista → All
Hardware: x86 → All
(In reply to comment #5)
> Here's the original testcase (with js file merged into SVG file).
(By "original testcase", I meant "the file spiro.svg mentioned in comment 4")
Regression range:
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101208 Firefox/4.0b8pre
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101209 Firefox/4.0b8pre
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=95452499f3d6&tochange=11e328a49e0a

Since the testcase seems to make extensive use of 'polyline', I'd guess that Bug 522308 is the most likely regressor.
Blocks: 522308
Summary: This page is very slow since firefox 4 (also minefield), firefox 3.16 was much faster → Perf regression since Firefox 3.6 with SVG Polyline element
Brian, I hope you can find time to look at this.
Assignee: nobody → birtles
Did a quick Shark profile of this.

97.7%  DOMSVGPointList::AppendItem
97.7%    nsSVGElement::DidChangePointList
97.1%      SVGPointList::GetValueAsString
91.4%        nsTextFormatter::snprintf

Our problem here seems to be that we changed from a notification mechanism that required no serialization, to a notification mechanism that does. Previously we would have had something more like this:

nsSVGPointList::AppendElement
  nsSVGValue::DidModify
    nsSVGValue::NotifyObservers
      nsSVGElement::DidModifySVGObservable
        nsAttrValue::nsAttrValue(nsISVGValue*)
        nsGenericElement::SetAttrAndNotify

Creating the nsAttrValue with a nsISVGValue* (the nsSVGPointList) avoided any serialization.

The fix for this bug is probably fixing bug 629200.
Yes, I guess so.
(It's maybe worth noting that the old world system, despite being quicker, wasn't completely correct. It would have had a similar problem to the one indicated in bug 610990 comment 16, meaning that restyles and mutation events would have been broken back then.)
(Assignee)

Comment 12

6 years ago
(In reply to comment #8)
> Brian, I hope you can find time to look at this.

Sorry, just back from being away. Sure, I'll take this. Presumably I should also take bug 629200 as well since that seems to be the root cause. Please feel free to steal from me though.
Status: NEW → ASSIGNED
(Assignee)

Updated

6 years ago
Depends on: 629200

Updated

5 years ago
Keywords: perf

Comment 13

5 years ago
Back up to speed again now post bug 629200
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Reporter)

Comment 14

5 years ago
Confirming fix. My original webpage http://www.mansoft.nl/spiro/spiro.htm now renders in less than a second.

Updated

4 years ago
Whiteboard: [in-the-wild] [external-report]
You need to log in before you can comment on or make changes to this bug.