MochiKit.DOM.getElementsByTagAndClassName performance

[takashi mizohata]

Hi All,

Forgive me, if this is a recurring argument.

Today I was looking at Firebug profiler and I realize that
getElementsByTagAndClassName takes certain percentages of processing
time. And I took a look at the code, and I did a little bit of hand
optimization. It doesn't change any semantics of code, but just
organizing code. It does pass the tests of course. And i got around
6% better performance.

Well the down side of this tweak may be the decrease of readability.
Since you need to carefully type comma between local variables. I
usually check it with jslint before commit in order to find those
potential mistakes. And obviously I don't much about coding
convention of MochiKit and I might need to edit the style of it.

Here I attached .patch file for this issue. Please try it and let me
know what you think. if somebody's interested in, I can contribute
some more performance tweaks in MochiKit.

Thanks,

--
Takashi M

[Per Cederberg]

Generally, I think some of these optimizations make sense. Like using
"===" instead of "==" in code like this:

typeof(x) === "string"

But I think the optimizations where variables are moved outside code
blocks and where array lengths are stored to variables should be used
with extreme caution. These are the type of things that people used to
recommend for Java code, but nowadays the virtual machines optimize
these things better by themselves. And what used to be a speedup
actually often leads to decreased performance.

For JavaScript, the VM:s are much more immature. But they are rapidly
becoming faster and more advanced. So low-level code optimizations
that result in a speedup today, might not do so just a year or two
down the road.

I think our focus here should be on clarity of intention. If some
critical-path function is extremely slow, we might want to have a look
at optimizing that specific function. But in general I think we should
refrain from low-level code optimizations that doesn't also improve
code readabilty and reduce the frequency of bugs.

Also, if speed is a problem, most serious speedups come from changes
to the algorithms and data structures involved. In this case for
instance, it might be faster to first find elements by class and then
filter out the ones with the correct tag. Or by using an
indexOf("class") on the className field before splitting it up. These
kind of optimizations will probably result in higher gains with less
reduction to the code readability.

Just my 2 cents.

Cheers,

/Per

[Bob Ippolito]

At least with recent browsers there are better ways to speed this up,
e.g. by leveraging more native code (getElementsByClassName and/or
XPath). None of them did this when the code was written in 2005 but I
think all of them do now (except maybe IE).

[Amit Mendapara]

Look at my mochikit-ext project at https://launchpad.net/mochikit-ext.
I have implemented a jQuery style API in MochiKit.Query module (http://
bazaar.launchpad.net/~amit-mendapara/mochikit-ext/trunk/files) which
is based on Sizzle.js (http://github.com/jeresig/sizzle).

MochiKit.DOM.getElementsByTagAndClassName("div", "some-class")

can be replaced with

MochiKit.Query("div.some-class").get()

The Sizzle.js is the fastest selector engine out there. See
http://www.hvergi.net/arnar/public/sizzle/speed/# for the speed tests.

Regards
--
Amit Mendapara

On Nov 4, 9:22 pm, Bob Ippolito <b...@redivi.com> wrote:
> At least with recent browsers there are better ways to speed this up,
> e.g. by leveraging more native code (getElementsByClassName and/or
> XPath). None of them did this when the code was written in 2005 but I
> think all of them do now (except maybe IE).
>

[Fredrik]

I created a getElementsByClassName based on this code:
http://robertnyman.com/2008/05/27/the-ultimate-getelementsbyclassname-anno-2008/
http://code.google.com/p/getelementsbyclassname/

Pending a full selector integration something like this should be an
easy drop-in
solution to optimize getElementsByTagAndClassName.
(IE really needs some speedup here..)

// Fredrik Blomqvist

On Nov 5, 7:45 am, Amit Mendapara <mendapara.a...@gmail.com> wrote:
> Look at my mochikit-ext project athttps://launchpad.net/mochikit-ext.

> I have implemented a jQuery style API in MochiKit.Query module (http://
> bazaar.launchpad.net/~amit-mendapara/mochikit-ext/trunk/files) which
> is based on Sizzle.js (http://github.com/jeresig/sizzle).
>
>     MochiKit.DOM.getElementsByTagAndClassName("div", "some-class")
>
> can be replaced with
>
>     MochiKit.Query("div.some-class").get()
>

> The Sizzle.js is the fastest selector engine out there. Seehttp://www.hvergi.net/arnar/public/sizzle/speed/#for the speed tests.

[Alex Russell]

On Nov 5, 2009, at 1:32 AM, Fredrik wrote:

>
> I created a getElementsByClassName based on this code:
> http://robertnyman.com/2008/05/27/the-ultimate-getelementsbyclassname-anno-2008/
> http://code.google.com/p/getelementsbyclassname/
>
> Pending a full selector integration something like this should be an
> easy drop-in
> solution to optimize getElementsByTagAndClassName.
> (IE really needs some speedup here..)
>
> // Fredrik Blomqvist
>
> On Nov 5, 7:45 am, Amit Mendapara <mendapara.a...@gmail.com> wrote:
>> Look at my mochikit-ext project athttps://launchpad.net/mochikit-ext.
>> I have implemented a jQuery style API in MochiKit.Query module
>> (http://
>> bazaar.launchpad.net/~amit-mendapara/mochikit-ext/trunk/files) which
>> is based on Sizzle.js (http://github.com/jeresig/sizzle).
>>
>> MochiKit.DOM.getElementsByTagAndClassName("div", "some-class")
>>
>> can be replaced with
>>
>> MochiKit.Query("div.some-class").get()
>>
>> The Sizzle.js is the fastest selector engine out there. Seehttp://www.hvergi.net/arnar/public/sizzle/speed/#for
>> the speed tests.

Actually, it's not. The Acme engine in Dojo beats it by a fair bit on
most real-world selectors. It's stand-alone and can be easily imported
(like Sizzle).

Regards