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
-~----------~----~----~----~------~----~------~--~---
