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
On Tue, Nov 3, 2009 at 23:23, takashi mizohata wrote:
> 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 mochikit@googlegroups.com
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
