Bug 105186 – V8 SerializedScriptValue assignment is expensive

• Component: WebCore JavaScript
• Status: RESOLVED WONTFIX

[Alec Flett]

After bug 104354 is fixed, the easiest interface to SSV is via Vector<uint8_t>

The problem is that when you assign a Vector<uint8_t> to the SSV, it immediately does a byte-swapping copy (using htons/ntohs) and when you read the buffer from the SSV it does a similar byte-swapping copy.

Two things need to be fixed:
1) The copy should be avoided by also having an adopt-ing constructor
2) The htons/ntohs for parsing/serializing should be happening in the parser/serializer

The reason this is important is that there are use cases (like IDB) where SSV is used as an intermediate stage that MIGHT never get parsed/deserialized.

The IDB case is: A key and value are read from the database, and passed up to a JS caller. The JS caller never looks at the "value" so we shouldn't be paying the price of mucking with those bits.

While there, the whole V8 SSV parser/serializer uses String as its interface, which is really broken simply from a code perspective because a String is a buffer of 16-bit characters, but the parser/serializer internally just deals with a stream of bytes.

[noel gordon]

(In reply to comment #0)

> While there, the whole V8 SSV parser/serializer uses String as its interface, which is really broken simply from a code perspective because a String is a buffer of 16-bit characters, but the parser/serializer internally just deals with a stream of bytes.

It's also broken from a performance perspective-- lots of extra data copying going on due to String, compared with the JSC SSV implementation.

Internally in the V8 SSV, the "stream of bytes" you mention is a WTF:Vector.  Exposing the SSV data to users is via String, as you note, means conversion from Vector->String first, but then the String is exposed on the API with String.isolatedCopy().   Yeap, that's yet another complete copy of the String data.

[Anders Carlsson]

V8 is gone.