O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na internet.
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.
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.
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.
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.
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).
> 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.
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).
> 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).
> > 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.
> 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).
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).
|
