[mochikit] Re: MochiKit.DOM.getElementsByTagAndClassName performance
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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit.DOM.getElementsByTagAndClassName performance
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 -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit.DOM.getElementsByTagAndClassName performance
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 -~--~~~~--~~--~--~---
