RESOLVED CONFIGURATION CHANGED 117192
david SVG nested use/symbol manipulation is extremely slow 
https://bugs.webkit.org/show_bug.cgi?id=117192
Summary SVG nested use/symbol manipulation is extremely slow
David Jander
Reported 2013-06-04 05:30:54 PDT
Created attachment 203686 [details] SVG nested use/symbol benchmark test When manipulating the SVG DOM in JavaScript of a SVG that uses nested use/symbol tags (up to 2 or 3 levels deep) execution gets extremely slow. On chromium/chrome or rekonq executing the attached file takes at least 13 seconds or much more (depending on browser/version), while firefox does the same in 54 milliseconds on the same machine!! Opening the attached file (svgbench.html) in different browsers produces the following results (total run time): Firefox 21 (reference): 0.054 s Chrome 14 (webkit 535.1): 13.650 s Chrome 21 (webkit 537.1): 23.240 s Chrome 27 (webkit 537.36): 26.250 s Chrome 29 (webkit 537.36): 28.380 s Rekonq 2.2.1 (KDE 4.10.2): 45.768 s All the above tests where run on 32bit Ubuntu 13.04 on an Intel core-i7 class PC. As can be seen, the performance differences with firefox are astronomical to say the least, and they are getting worse with every new version of webkit. svgbench.html contains some JavaScript functions that are executed in a sequence, while logging the running time at the start and the end of each function in a <pre> tag below. part0() creates 200 <symbol> tags with a <text> tag inside and appends them to the <defs> tag of the SVG. part1() modifies the text content of each text tag. part2() adds 200 more <symbol> tags, that each contain a <use> href to one of the previous <symbol> tags. part3() again modifies the 200 <text> tags part4() adds 200 <use> tags to the "mainsym" <symbol> href pointing to the symbols created in step 3. This makes all of the <text> tags become visible. part5() again modifies the 200 <text> tags. The first 4 functions execute very quickly all of the time. It's part4() and part5() that take huge amounts of time on webkit-based browsers.
Attachments
SVG nested use/symbol benchmark test (2.89 KB, text/html)
2013-06-04 05:30 PDT, David Jander 		no flags
Details
An SVG with lots of nesting (1.71 MB, application/zip)
2013-08-23 01:23 PDT, ndmuir 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
ndmuir
Comment 1 2013-08-23 01:13:33 PDT
This is causing problems for my application. What's necessary to have this issue diagnosed / resolved?
ndmuir
Comment 2 2013-08-23 01:23:54 PDT
Created attachment 209441 [details] An SVG with lots of nesting Added an example SVG from a chrome bug report - renders instantly in firefox, or over approx 15-20secs in chrome.
David Jander
Comment 3 2013-08-23 01:46:41 PDT
Vector.svg indeed renders much slower in chrome than in firefox, but I doubt this has anything to do with this particular problem, since Vector.svg does not have <use>/<symbol> nesting at all.
Ahmad Saleem
Comment 4 2022-08-12 09:06:17 PDT
*** Safari Technical Preview 151 *** 0.003 : Creating... 0.004 : Creating done. 0.009 : Modifying hidden... 0.010 : Modifying hidden done. 0.020 : Using indirect... 0.020 : Using indirect done. 0.029 : Modifying indirect... 0.030 : Modifying indirect done. 0.043 : Using second level... 0.044 : Using second level done. 0.101 : Modifying visible... 0.101 : Modifying visible done. *** Firefox Nightly 105 *** 0.003 : Creating... 0.005 : Creating done. 0.007 : Modifying hidden... 0.008 : Modifying hidden done. 0.010 : Using indirect... 0.011 : Using indirect done. 0.015 : Modifying indirect... 0.016 : Modifying indirect done. 0.017 : Using second level... 0.018 : Using second level done. 0.035 : Modifying visible... 0.036 : Modifying visible done. *** Chrome Canary 106 *** 0.011 : Creating... 0.012 : Creating done. 0.022 : Modifying hidden... 0.022 : Modifying hidden done. 0.026 : Using indirect... 0.027 : Using indirect done. 0.028 : Modifying indirect... 0.029 : Modifying indirect done. 0.030 : Using second level... 0.031 : Using second level done. 0.068 : Modifying visible... 0.069 : Modifying visible done. _________ We are bit slow but not as much as we use to be in 2013 and our computer hardwares have evolved leaps and bounds these days. Can someone please mark this accordingly. Thanks!
Alexey Proskuryakov
Comment 5 2022-08-20 15:10:31 PDT
Since this is a micro-benchmark and not a comprehensive benchmark, we don't necessarily need to be the fastest. And the originally reported pathological slowness is clearly fixed. Please reopen or file a new bug is there is still a user observable performance issue here.
Note You need to log in before you can comment on or make changes to this bug.