Looking at Runtime_HasElement it does not really have any fast path for dense arrays. (it does tons of checks before it reaches GetElementsAccessor()->GetAttributes(...)). Which explains why speedup is minor and it also indicates that unconditionally replacing "in" with something simpler would most certainly violate some semantical expectations.
Vyacheslav Egorov On Tue, Aug 13, 2013 at 7:07 PM, Erik Arvidsson <[email protected]> wrote: > HasElements is 21% faster than existing code and it still passes all tests. > > I'll provide a new CL that only does that. > > > On Tue, Aug 13, 2013 at 12:05 PM, Vyacheslav Egorov > <[email protected]>wrote: > >> s/%HasElement(i, array)/%HasElement(array, i)/ >> >> Vyacheslav Egorov >> >> >> On Tue, Aug 13, 2013 at 6:04 PM, Vyacheslav Egorov >> <[email protected]>wrote: >> >>> DBC: >>> >>> Can't we just manually inline 'in' here? >>> >>> if I am not mistaken x in y essentially just calls IN function from >>> runtime.js >>> >>> In this particular case you should be able just to replace i in array >>> with %HasElement(i, array) and hopefully fast path in the %HasElement would >>> take care of the rest. >>> >>> Ideally Crankshaft should take care of this but well... One can dream :-) >>> >>> Vyacheslav Egorov >>> >>> >>> On Tue, Aug 13, 2013 at 5:47 PM, <[email protected]> wrote: >>> >>>> >>>> https://codereview.chromium.**org/22545007/diff/20001/src/**array.js<https://codereview.chromium.org/22545007/diff/20001/src/array.js> >>>> File src/array.js (right): >>>> >>>> https://codereview.chromium.**org/22545007/diff/20001/src/** >>>> array.js#newcode1263<https://codereview.chromium.org/22545007/diff/20001/src/array.js#newcode1263> >>>> src/array.js:1263: if (!isProxy && %HasFastPackedElements(array) || i in >>>> array) { >>>> On 2013/08/13 14:10:22, Michael Starzinger wrote: >>>> >>>>> It is _really_ surprising that the runtime call into >>>>> Runtime_HasFastPackedElements is cheaper than the "in" keyword. This >>>>> >>>> suggests >>>> >>>>> that there is a lot of potential in actually improving "in" in >>>>> >>>> general. This >>>> >>>>> needs investigation of the generated code! >>>>> >>>> >>>> Now that I think about it, I don't actually think that this is a valid >>>> optimization either. What happens if the callback actually changes the >>>> array in a way so that it remains in fast-packed mode, but "i" still >>>> runs out of bounds. Imagine the following callback. >>>> >>>> var array = [1,2,3,4,5,6]; >>>> Object.defineProperty(array, '1', { >>>> get: function () { array.length = 3; }, >>>> configurable: true >>>> }); >>>> array.forEach(f); >>>> >>>> >>>> https://codereview.chromium.**org/22545007/<https://codereview.chromium.org/22545007/> >>>> >>>> -- >>>> -- >>>> v8-dev mailing list >>>> [email protected] >>>> http://groups.google.com/**group/v8-dev<http://groups.google.com/group/v8-dev> >>>> ---You received this message because you are subscribed to the Google >>>> Groups "v8-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to >>>> v8-dev+unsubscribe@**googlegroups.com<v8-dev%[email protected]> >>>> . >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>> . >>>> >>> >>> >> > > > -- > erik > > > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
