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

Re: [Public WebGL] typed arrays + edge cases

> 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).

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)"

>    - 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: