Closed
Bug 686560
(bytearray-tracker)
Opened 13 years ago
Closed 6 years ago
Optimizations for ByteArray
Categories
(Tamarin Graveyard :: Virtual Machine, defect, P3)
Tamarin Graveyard
Virtual Machine
Tracking
(Not tracked)
RESOLVED
WONTFIX
Q2 12 - Cyril
People
(Reporter: lhansen, Unassigned)
References
Details
(Whiteboard: PACMAN, Tracking)
This is a placeholder tracker bug for ByteArray optimizations / investigations. ByteArray should be optimized along the same ways as Array and Vector: methods should be early-bound, or ideally inlined with inline and fast range checks, when possible, for the most common cases (especially when the destination is of the proper type). Callouts, when used, should be flattened as much as possible and optimized. The ByteArray method suite should target important use cases, such as bulk copying or bulk conversion to/from Vector or dense Array.
Assignee: nobody → lhansen
Flags: flashplayer-qrb+
Flags: flashplayer-injection-
Flags: flashplayer-bug-
Priority: -- → P2
Target Milestone: --- → Q1 12 - Brannan
Reporter | ||
Comment 1•13 years ago
|
||
Since ByteVector is not a final class and its methods are also not final, we can benefit from tricks devised elsewhere: - As for Array we can use a private 'length' field to hold the true length of the ByteArray as well as serve as a flag for whether the object is a true ByteArray (or at least whether it has overridden methods), provided we know that the static type of an object is ByteArray. Using this as a guard we can inline most methods that are short enough. - Getting fanciful: There could me multiple length fields, which would be nonzero if the true length is a multiple of two, four, or eight bytes. Don't know what follows from that yet, but there ought to be some sort of upside for multi-byte accesses, eg, they hold the true length less one, less three, less seven, and thus prevent us from having to adjust the index value in the range check. But the cost of maintaining the fields may not be worth it. They could be updated lazily (on the first trap) and cleared in various ways when extending the vector, not too hard. - More useful maybe: One length field for little-endian and one for big-endian; the inlined version would have a preference for the native encoding. Getting this implemented is not going to be pretty, ByteArray is shockingly complicated and the call hierarchy is deep.
Reporter | ||
Updated•13 years ago
|
Alias: bytevector-tracker
Reporter | ||
Comment 2•13 years ago
|
||
Speaking of ByteArray features, it's arguably a missing feature that endianness cannot be set to "native", because native-endianness reading and writing can be quite a bit faster once we start optimizing properly. Applications that only need native endianness can arguably use Vector for that in most cases, but there might still be some utility to such a setting. Perhaps a simpler or complementary method would be to provide a static getter that returns the string for native endianness.
Reporter | ||
Updated•13 years ago
|
Alias: bytevector-tracker → bytearray-tracker
Reporter | ||
Comment 3•13 years ago
|
||
For the "random access" case (setting position before every call to a read/write function) it will be helpful to in-line the ByteArray.position setter, which will be very hot but which is essentially a trivial function. It should be straightforward to inline the getter and setter for operator[] since it does not depend on endianness or position, only on the index and the length. Also it's not affected by subclassing, at least not on the AS3 side - do we need to worry about the C++ side? (Essentially it's inlining of getUintProperty / setUintProperty.) In the case where an "int" is used to access a bytearray with operator[] we should make sure that we hit the getUintProperty / setUintProperty case, and ideally optimize the range check properly so that there's only a single compare.
Reporter | ||
Comment 4•13 years ago
|
||
(In reply to Lars T Hansen from comment #2) > Speaking of ByteArray features, it's arguably a missing feature that > endianness cannot be set to "native", because native-endianness reading and > writing can be quite a bit faster once we start optimizing properly. > Applications that only need native endianness can arguably use Vector for > that in most cases, but there might still be some utility to such a setting. > Perhaps a simpler or complementary method would be to provide a static > getter that returns the string for native endianness. The obvious location for that would be the Endian class (which currently exports BIG_ENDIAN and LITTLE_ENDIAN properties holding the proper strings).
Reporter | ||
Comment 5•13 years ago
|
||
Bug #692044 and bug #692042 are targeted for Brannan, but other optimizations will make it into Cyril at the earliest. Therefore retargeting the tracker for Cyril.
Priority: P2 → P3
Target Milestone: Q1 12 - Brannan → Q2 12 - Cyril
Reporter | ||
Updated•12 years ago
|
Assignee: lhansen → nobody
Comment 6•6 years ago
|
||
Tamarin isn't maintained anymore. WONTFIX remaining bugs.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•