> 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
>
> On Nov 4, 9:22 pm, Bob Ippolito <
b...@...> 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...@...> 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...@...> 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.
getElementsByTagAndClassName.patch (2K) 