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.
(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.
V8 is gone.