100% Rolf, definitely always going to be an over head from a library. The reason why I included the last two tests are that I was interested in what the overhead is/was and I hadn't used jsperf before so I maybe got a little excited :) It was a flawed test anyhow, it destroyed an element every execution where as the others didn't. The last 2 tests were just play, the createTextNode and docFrag where the test more of interest (and fairer). Can't remember the last time I injected 25 thousand new elements into an element :)
Pretty sure the 'true' allows document.id to return an element that hasn't been extended with the Mootool's Element methods (defaults falsy). There's a third argument 'doc' as well, that allows you to specify a different 'document' to reference. Is there more to it mootools? :) On May 26, 7:36 am, Rolf -nl <[email protected]> wrote: > btw a bit OT, but what does the true do in document.id(var, true)? I > didn't see it in the documentation and I can't find it in the source > (I see/saw it being used in the source multiple times, but couldn't > trace it back quickly enough) > > On May 25, 11:14 pm, Rolf -nl <[email protected]> wrote: > > > > > > > > > So with the documentFragment and createTextNode are almost as fast, > > but the documentFragment is better used if you want to insert more > > than one nodes (before/after) some element. Of course you could also > > check with if it matters if the to-be-inserted nodes are just > > textnodes or a bit more than that. > > > I remember some earlier threads about jsperf though > > (eg.http://groups.google.com/group/mootools-users/browse_thread/thread/bd...) > > so comparing the inject/destroy vs two mentioned before is not really > > a good comparison probably (I mean comparing the vanilla js with the > > moo-methods is a bit "silly") > > > On May 25, 3:33 pm, robdb <[email protected]> wrote: > > > > Out of interest, put the above methods into jsperf. Plus a > > > 'createTextNode' method clone without caching the $$ function, always > > > going to be slower, little surprised by how much though. Apparently > > > IE6 (under a virtual machine) performs better than Opera 11.10 apart > > > from the Inject-Destroy method where it failed with the ol 'Object > > > does not support this prop or method'. > > > Didn't include the fiddle I put up previously, compared to the > > > documentFragment and createTextNodemethods, it was sluggish (and very > > > 2am not awsome...), always a little slower than 'Inject-Destroy'. > > > >http://jsperf.com/docfrag-textnode-insertion > > > > On May 25, 6:37 pm, Rolf -nl <[email protected]> wrote: > > > > > of course, you're right > > > > > On May 24, 10:51 pm, Michael Russell <[email protected]> wrote: > > > > > > you really don't need a fragment for that. > > > > > > this: > > > > > > var elements = $$('span'); > > > > > elements.each(function(elm){ > > > > > var fragment = document.createDocumentFragment(); > > > > > fragment.appendChild(document.createTextNode('X')); > > > > > elm.parentNode.insertBefore(fragment, elm.nextSibling); > > > > > > }); > > > > > > could just be: > > > > > > var elements = $$('span'); > > > > > elements.each(function(elm){ > > > > > var txtNode = document.createTextNode('X') > > > > > elm.parentNode.insertBefore(txtNode, elm.nextSibling); > > > > > > }); > > > > > > Fragments are really nice when you don't want to inject a wrapper > > > > > element > > > > > but want to insert n+1 nodes into the DOM. Using it will cause the > > > > > browser > > > > > to only re[paint/structure] the DOM once when injecting them instead > > > > > of on > > > > > each iteration of your elements array
