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).
On Tue, Nov 3, 2009 at 11:14 PM, Per Cederberg <cederb...@gmail.com> wrote:
>
> 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 <bea...@gmail.com> 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
-~----------~----~----~----~------~----~------~--~---
