[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] typed arrays + edge cases



On 2/4/2010 1:42 PM, Oliver Hunt wrote:
Well, like I said, it buys us the ability to more efficiently reason about the object. For our implementation at least, it's a big performance boost if for each access, we know ahead of time what the type will be. It lets us generate much more efficient code, without inserting tests and branches along the way. In addition, making these inextensible makes it easier for developers to track down wrong behaviour, such as out of bounds access. The focus of these types is native type interoperability and performance; I don't think we should ignore any potential performance boost, especially when it's one that only affects the form some code takes, rather than making it possible/impossible to do something.
In our implementation it would be a slow down :D -- But realistically i don't see how it interferes with your ability to reason about the type -- if we assume similar behaviour to array-likes in the DOM then all array indexed access is either in bounds so will be a normal lookup, or out of bounds so will be undefined. Writes beyond the length of the array have no effect (because length is immutable).

Ok, so this is different than what I thought Chris was proposing -- that we actually accept out of bounds access. Having the dom-like behaviour seems fine.


This means the only form of access that you're left with are non-array-index property names which you have to be able to handle anyway, and i would assume that that isn't going to be hot code in the same way indexing is.

If you could actually explain why making the object is inextensible is a guaranteed performance improvement beyond details of your specific implementation i would be welcome to hear it, but in all honesty the cost of having to explain "these arrays behave differently from every other object" for an unclear, browser dependent perf improvement seems far greater than a specific browser saying "for optimal performance in<insert browser name here>, it may be beneficial to call Object.preventExtensions on the array)"

Yeah, the main issue I had was with out of bounds indexed array access. The other stuff isn't as bad. So, ok:


- length is read-only;
- reads out of the range of 0..length-1 result in undefined;
- sets outside of that same range are ignored;
- and non-numeric properties work like normal object properties.

That look right?

    - Vlad

-----------------------------------------------------------
You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: