next(Number) slowdown in Internet Explorer (6,7)
vkojo...@gmail.com
also prev() and the rest of the navigation function) cause a
tremendous slowdown in IE if they are used with the following syntax:
next(Number). From what I saw in the code, that translates to a
Selector with a '*' expression. Using next(null, 1) solves the
slowdown problem. Also, since this might be related,
getElementsByClassName is also very slow in this release.
Mislav Marohnić
Andrew Dupont
wrote:
> With the latest prototype (1.5.1), the next() function (and probably
> also prev() and the rest of the navigation function) cause a
> tremendous slowdown in IE if they are used with the following syntax:
> next(Number). From what I saw in the code, that translates to a
> Selector with a '*' expression. Using next(null, 1) solves the
> slowdown problem.
This is troubling to me. I could've sworn I fixed this back when I
wrote the Selector code, but perhaps I just fixed it for the no-
arguments case and not the one-numeric-argument case. We'll address
this in 1.5.2.
> Also, since this might be related,
> getElementsByClassName is also very slow in this release.
Compared to which release? Care to post some benchmarks?
Cheers,
Andrew
Mislav Marohnić
> Also, since this might be related,
> getElementsByClassName is also very slow in this release.
Compared to which release? Care to post some benchmarks?
vkojo...@gmail.com
Sorry no benchmarks. That was just from the top of my memory. My
reason for putting 'in this release' in there was, that I didn't
notice any slowdowns when using getElementsByClassName in previous
releases (that were noticeable in this release, at least).
>
> Cheers,
> Andrew
Andrew Dupont
wrote:
> Andrew, it doesn't matter - getElementsByClassName tends to extend EVERY
> node in the document! If that isn't slow I don't know what is.
No, it doesn't. It extends only those nodes that match the class
name. I've personally spent quite a bit of energy to ensure that
getElementsByClassName performs as well as possible under the
circumstances, even in IE.
To the author: nothing has changed about the behavior of
getElementsByClassName since 1.5.0 final. It's *possibly* slower than
it was in 1.4 final (because of the cost of extending each node with
instance methods) -- but there have been some optimizations since 1.4,
too. If it seems slower to you in the future, try doing a side-by-side
comparison -- the Test.Unit framework packaged with the full source of
Prototype makes it easy to run benchmarks. That way we can get some
hard numbers.
Cheers,
Andrew
Tobie Langel
slower the methods will be - obviously!
Mislav Marohnić
It extends only those nodes that match the class name.
It calls Element.hasClassName for every node, I hope we can agree on that. Now, let us remember what do methods from the Element namespace all have in common.
Hint: it has something to do with the first argument and the $ function.
Andrew Dupont
wrote:
> It calls Element.hasClassName for every node, I hope we can agree on that.
> Now, let us remember what do methods from the Element namespace all have in
> common.
>
> Hint: it has something to do with the first argument and the $ function.
Wow. That's a show-stopper. We need to fix this immediately.
(Apologies, Mislav.)
I worked on getElementsByClassName optimization about six months ago.
Sometime after that, it was changed to use Element.hasClassName --
presumably to stay DRY, but at a huge performance cost. I haven't
noticed this because I've given up getElementsByClassName almost
entirely -- in favor of $$ and getElementsBySelector.
Everyone on Core needs to understand: in IE, the cost of calling $ is
trivial in a single case, but in a loop it can be the difference
between instantaneous loading and a thirty-second freeze. That's why I
had to write new versions of all these functions for selector.js: I
needed functions that did not call $ or Element.extend, so that I
could be sure that no elements were extended until the final result
set.
Prototype isn't an optimize-first library, but every function that
queries the DOM needs every millisecond squeezed out of it. Since
there is no limit to the number of nodes on a page, there is no DOM
querying scenario that will not become a performance issue when taken
to its logical edge case (one needle, gigantic haystack). So we need
to be extra sensitive about this. Perhaps we should set some minimum
performance standards and run a couple benchmarks automatically as
part of the unit tests.
Once again to the original author: in light of this new information, $
$ should be faster than getElementsByClassName. This is both true and
ridiculous.
Cheers,
Andrew