MochiKit.DOM.getElementsByTagAndClassName performance

Discussion:

takashi mizohata

2009-11-03 22:23:09 UTC

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Per Cederberg

2009-11-04 07:14:04 UTC

Permalink

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

Post by 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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Bob Ippolito

2009-11-04 16:22:12 UTC

Permalink

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).

Post by Per Cederberg
Generally, I think some of these optimizations make sense. Like using
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

Amit Mendapara

2009-11-05 06:45:39 UTC

Permalink

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

Post by 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).

Fredrik

2009-11-05 09:32:21 UTC

Permalink

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

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.
Regards
--
Amit Mendapara

Alex Russell

2009-11-05 21:42:41 UTC

Permalink

Post by Fredrik
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

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---