105186 2012-12-17 09:00:57 -0800 V8 SerializedScriptValue assignment is expensive 2013-09-25 08:36:14 -0700 1 1 1 Unclassified WebKit WebCore JavaScript 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 104354 1 alecflett webkit-unassigned andersca noel.gordon oldest_to_newest 792766 0 alecflett 2012-12-17 09:00:57 -0800 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. 828154 1 noel.gordon 2013-02-07 21:03:36 -0800 (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. 933025 2 andersca 2013-09-25 08:36:14 -0700 V8 is gone.