Actually I did make a test case --
http://groups.google.com/group/prototype-core/web/element%23siblings.zip --
zipped to take less space from the quota.
For fair tests, I extracted the methods as simple functions.
Note:
* The first click is noticably slower then the rest of the clicks.
* Actual exectution vary for me on every page refresh.
I get 5ms for the ad hoc method and 7 for the proto method.
2009/9/3 kangax kan...@gmail.com
On Sep 2, 6:25 pm, joneff jon...@gmail.com wrote:
(It's kinda long and it might be for the other prototype group, but I
am not sure.)
I was poking around with a script for manipulating tables which takes
heavy use of Element#siblings for some of the manips.
And I found that in some cases it [the method] tends to be slow. Not
slow like Vista on a 486 PC but slow as in a bit slower than I
expected.
But then again I am usually testing on 1000 row tables with enough
cols to make FF choke and was like maybe it's supposed to be like
that. maybe if I use querySelectorAll it will be faster.
I mean, I do remember an immediate following sibling selector (+) and
all following siblings selector (~). It seemed to me, that there
should be ALL siblings selector. Alas I was wrong. Not to mention it's
kinda wicked to work with qSA.
So what I did was to dig in prototype code and find the
Element#siblings. I admit it's logic is perfect -- ALL siblings = next
siblings + following siblings. The only thing that bothered me was the
amount of function calls -- I mean this function call that function,
and calls another one, and another one and so on and so forth.
Note: I am do CSS for a living. Thus I have absolutely no idea how
much time it takes (if any) to jump from a function to function.
Anyway, I made my way up the function, trying to keep the code general
feeling and I was left with this
siblngs: function (element) {
if (!element) return [];
element = element.parentNode.firstChild, elements = [];
while (element) {
if (element.nodeType == 1 element != arguments[0])
elements.push
(Element.extend(element));
element = element.nextSibling;
}
return elements;
}
which, I have to admit wasn't as faster as I expected.
Anyway, I went over to jQ and mT to see how they do it.
jQ's approach was more or less similar. It does use this weird for
statement (translated to fit) -- (;element;element.nextSibling) --
instead of the while, but the I guess that wouldn't make a difference.
mT was even more exotic then the original Prototype method, but kinda
has the same spirit as the one above.
Sooo... Like I noticed in the beginning, that was long, and I am still
not sure it's for this group, and I having in mind I do CSS for a
living, I am asking -- is this improved Element#siblings faster?
Why not make a simple test case to see if it really is faster?
--
kangax
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---