Somewhere there's obviously got to be a bounds check, in order to not overwrite memory outside the array. Why does the requirement that the failure of this bounds check cause a TypeError make the inbounds case any more expensive? The specified difference in behavior is only what happens following the failure of the bounds check.
On Wed, Feb 25, 2015 at 4:40 PM, Jeff Walden <[email protected]> wrote: > Currently, the behavior of IntegerIndexedElementSet is to return false if > the index being set is outside the array bounds. This return-false > directly feeds into the result of [[Set]] on a typed array. The result is > that in strict mode code, setting an out-of-bounds array element throws a > TypeError. > > I've heard claims from other SpiderMonkey implementers that this > requirement makes it difficult to implement high-performance JIT > optimizations for code that assigns into typed arrays, except in the case > that the array length is observable in context, the typed array never > escapes anywhere, its backing ArrayBuffer never escapes anywhere, etc. > Restrictions that generally aren't very easy to determine with local > information observable by a JIT. And while quite often such > high-performance code isn't strict mode code, it's doubtful that will be > true far into the future. > > From that point of view, it would be better if IntegerIndexedElementSet > just returned true in this case -- indicate success without doing > anything. What are the compelling reasons to not do this? > > Jeff > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
