Closed
Bug 379533
Opened 18 years ago
Closed 15 years ago
Incremental XML results in DOM performance hit at load time
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: duncan.loveday, Unassigned)
Details
(Keywords: perf, regression, Whiteboard: [external-report])
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070422 Minefield/3.0a4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070422 Minefield/3.0a4pre
Since the changes for incremental XML, javascript code that updates the SVG DOM runs much more slowly. The reasons why this is so are largely understood and can be worked around given an understanding of the reasons - see bug 374037. This separate bug is raised to discuss the issue about whether or not it is acceptable to release a version requires workarounds to be understood and applied to achieve the same level of performance as earlier versions.
Reproducible: Always
Steps to Reproduce:
Please refer to bug 374037.
Actual Results:
Populating the SVG DOM is much slower because of incremental XML.
Expected Results:
As an "outsider" I was surprised and disappointed by this slowdown in the javascript code. Having raised a bug and got slightly involved in the ensuing debate, I understand a little about the reasons for it but I still feel there is likely to be a flood of bug reports when web developers find their javascript code is so much slower than before. I think consideration ought to be be given to some way of eliminating this impact of incremental XML loading when in conjunction with javascript DOM manipulations.
This might be one where an informed consensus needs to be reached. I notice that bug 374037 has been nominated as blocking 1.9 but the likelihood is that the impact of incremental XML will always be noticeable and people wanting their code to perform as well as it did on earlier versions will need to use one of the workarounds mentioned in bug 374037. This debate is just about whether it is reasonable for web developers to be expected to do that. This is a separate debate, I think, to the one about whether the impact of incremental XML should be reduced through a gradual process of refining and tuning the code.
Reporter | ||
Updated•18 years ago
|
Keywords: perf,
regression
Please note that modifications only got slower before the document is fully loaded. If you made modifications after the document was fully parsed then the way you were making them were slow even in FF2.
So what's happened is that we now behave the same thoughout the lifetime of the doc, whereas we used to be faster until the document was fully parsed.
Also, i suggest bringing this up in the newsgroups instead. Bugzilla isn't a good way to get input on this.
Reporter | ||
Comment 2•18 years ago
|
||
(In reply to comment #1)
> Please note that modifications only got slower before the document is fully
> loaded. If you made modifications after the document was fully parsed then the
> way you were making them were slow even in FF2.
Yes, indeed, the hit was always there - in fact the hit is significantly reduced in FF3 as documented in bug 374037.
>
> So what's happened is that we now behave the same thoughout the lifetime of the
> doc, whereas we used to be faster until the document was fully parsed.
That's my point - you've made it consistent but at the slower speed. People building SVG using javascript and the DOM will be disappointed by this, bearing in mind the benefits of incremental XML parsing won't apply to them anyway since the results of a script are normally only seen on completion anyway (except in rare circumstances such as when a script alerts).
>
> Also, i suggest bringing this up in the newsgroups instead. Bugzilla isn't a
> good way to get input on this.
>
I'm happy to do this but I'm not sure how that would lead to a fix. Which news group would you suggest (my interest in Mozilla bugs etc is rather new).
Personally, I don't think this can be "fixed". We can certainly improve our speed when it comes to mutating DOMs that has layout attached, by better batching and things like that. But it's never going to be as fast as when no layout is attached.
The only thing we could do would be to disable incremental rendering, which I think is even worse.
But you said you wanted to have a discussion if this was an acceptable slowdown or not, that's the discussion I suggest you take in the NGs. Probably mozilla.dev.tech.xml and/or mozilla.dev.tech.svg
Reporter | ||
Comment 4•18 years ago
|
||
OK I've created a post at http://groups.google.com/group/mozilla.dev.tech.svg/browse_thread/thread/b3aa0cd6e7c061e0/12065f921fb8513b#12065f921fb8513b
I think disabling incremental rendering (and layout) while a script is running would be a great idea.....but then I don't know anything about it really. Just want it to go faster.
Updated•15 years ago
|
Assignee: general → nobody
QA Contact: ian → general
Comment 5•15 years ago
|
||
We're not going to disable incremental rendering. We will make specific performance improvements to rendering speed as and where we can.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
![]() |
||
Updated•11 years ago
|
Whiteboard: [external-report]
You need to log in
before you can comment on or make changes to this bug.
Description
•