Closed Bug 686560 (bytearray-tracker) Opened 13 years ago Closed 6 years ago

Optimizations for ByteArray

Categories

(Tamarin Graveyard :: Virtual Machine, defect, P3)

defect

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
Depends on: 685458
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.
Depends on: 633296
Depends on: 687045
Alias: bytevector-tracker
Depends on: 687046
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.
Alias: bytevector-tracker → bytearray-tracker
Depends on: 692042
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.
Depends on: 692044
(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).
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
Assignee: lhansen → nobody
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.