Just to be clear what I'm talking about:
say we have something like:
events = {}
events.foo = 17
events.bar = 19
and then
for(var prop in events) {
// do stuff with foo and bar
}
we could instead do something like:
events = {}
events.props = []
events.foo = 17
events.props.push("foo")
events.bar = 19
events.props.push("bar")
and then:
for(var i=0, j=events.props.length, i<j; i++) {
// do stuff with events[events.props[i]]
}
which should be roughly as fast as a regular for/in (especially if
events.props is cached before the loop), but requires control over the
object. In certain internal objects that are on the critical paths of apps,
like events, we have this control.
-- Yehuda
On Fri, Oct 3, 2008 at 12:53 PM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
> Different cases here possibly call for different approaches.
> In the case (like in events), where we're in charge of setting up the keys,
> why not keep a separate Array around with a list of the keys. I'm talking,
> for instance, about line 306 and 307 in core.js.
>
> In certain other cases (like setting attributes via Objects), doing the
> typical performance-intensive checks might not be such a big deal.
>
> Basically what I'm saying is: let's not completely ignore the possibility
> of using a more expensive version of the loop in startup cases; focus on
> keeping the critical path fast (events, selector, etc.)
>
> -- Yehuda
>
>
> On Fri, Oct 3, 2008 at 10:47 AM, Ariel Flesler <[EMAIL PROTECTED]> wrote:
>
>> console.log("raw time", +new Date - start);
>>
>> +new Date --> Yeah!
>>
>>
>>>
>>> start = +new Date;
>>> for (var i = 0; i < 1000; i++) {
>>> var tainted = Object.tainted();
>>> for (var key in test) {
>>> if (!tainted || !Object.prototype[key]) {
>>> fn(key, test[key]);
>>> }
>>> }
>>> }
>>> console.log("checked time", +new Date - start);
>>>
>>> The second version seems be about 15 to 20 % slower, but thats for a
>>> million iterations... There difference is much smaller for this
>>> version:
>>>
>>
>> 20% seems like a relevant percent to me. This is most called method.
>> Note that having firebug on, messes up numbers. Specially for function
>> calls (Object.tainted).
>> I'd try that w/o firebug.
>>
>> As a small improvement:
>>
>> var clean = !Object.tainted();
>>
>> Saves you one boolean cast for each iteration.
>>
>>
>>> I've modified $.each to include the Object.prototype check and ran it
>>> against ?core&selector, couldn't see any performance difference, if
>>> anything, it seemed to be faster. Not a good benchmark either, but
>>> from what I see, just doing the Object.prototype check, maybe caching
>>> the Object.prototype lookup in a local var, is safe and irrelevant for
>>> performance.
>>>
>>
>> Did you tried that (caching in a var) with a benchmarker ?
>>
>> --
>> Ariel Flesler
>> http://flesler.blogspot.com
>>
>> >>
>>
>
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
