search

azuma2015 / swfobject

Automatically exported from code.google.com/p/swfobject
1 stars 0 forks source link

Slowness when manipulating DOM because of test in callDomLoadFunctions #418

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
// test if we can really add/remove elements to/from the DOM; we don't want
to fire it too early
var t = doc.getElementsByTagName("body")[0].appendChild(createElement("span"));
t.parentNode.removeChild(t);
}

Above rows in swfobject 2.2 makes a page that makes very many DOM
manipulations later extremely slow when it does these manipulations.
If I comment out the two rows, the page is lightning fast again.

The page has no flash in it, so it took some debugging skills to narrow the
problem down to being something you might see as unrelated to be the culprit.

Tested in firefox 3.5.5 and firefox trunk 20091225 on windows xp sp3.

Original issue reported on code.google.com by dele...@gmail.com on 26 Dec 2009 at 4:58

GoogleCodeExporter commented 9 years ago 
In 2.1 the code above ran only in IE on windows, now it runs on all browsers. 
That is
why it was not a problem in 2.1 for firefox on windows.

Why it makes firefox slow I don't know, but my guess would be that it destroys 
some
nifty caching mechanism firefox has by manipulating the DOM before it is 
"ready".

Original comment by dele...@gmail.com on 26 Dec 2009 at 6:51

GoogleCodeExporter commented 9 years ago 
OK, now I have done some serious research about what is causing the extreme 
slowdown.
 We have a map application which draws markers for positions and during the drawing
of each marker this is called:

document.body.removeChild(this.tmpImg);

This call is painfully slow when the rows in swfobject2.js mentioned in the bug
report are active (not commented out). Commenting out the rows in swfobject2.js 
makes
the removeChild call in our map application lightning fast again.

So this is not a bug in swfobject per se, but a bug in firefox. I strongly 
advice
though to rewrite the two rows in another way that does not make subsequent 
calls to
removeChild extremely slow. 

The fewer consumers of this fine library that do not have insanely illogical
performance issues the better. ;)

Original comment by dele...@gmail.com on 11 Jan 2010 at 2:00

GoogleCodeExporter commented 9 years ago 
Thanks for spending the time to investigate this issue further.

Original comment by aran.rhee@gmail.com on 11 Jan 2010 at 11:12

GoogleCodeExporter commented 9 years ago 
There is an attempt to use document.getElementsByTagName("body")[0] before it 
is defined. Since try/catch is expensive, I have added a simple test 
if(!document.getElementsByTagName("body")[0]) to ensure <body> is available 
before attempting to add a <span>. Hopefully this clears up some of the 
slowness reported in this thread.

Original comment by platelu...@gmail.com on 21 May 2011 at 6:43