On 5/12/09 9:20 AM, "Bryan Duxbury" <[email protected]> wrote:
>> 1. The performance figures that thrift-protobuf-compare provides
>> for dynamic
>> serialization systems like JSON are not currently valid since the
>> tests do
>> not really test them as a fully general serialization/deserialization
>> framework.
>
>You mean that since they coded their json serialization directly to
>their test data, the performance data is inaccurate? This might be
>true in the sense that their serialization doesn't do some things
>that Thrift does, but since we generate code, I don't think it's
>*that* different.
No, it's much worse than that, at least as I see it. The dynamic serializers
are quite tightly bound to the data that is provided in the create() method,
not just to the data structure. This means that they are "cheating" in ways
that allow them to avoid putting In metadata they would need to do valid
serialization/deserialization in a general way and they also avoid doing a
bunch of switching that they would be required to do things correctly.
Look at StdMediaSerializer::create():
public final MediaContent create() throws Exception
{
Media media = new Media(null, "video/mpg4", Media.Player.JAVA, "Javaone
Keynote", "htt
p://javaone.com/keynote.mpg", 1234567, 123, 0, 0, 0);
media.addToPerson("Bill Gates");
media.addToPerson("Steve Jobs");
Image image1 = new Image(0, "Javaone Keynote", "A", 0,
Image.Size.LARGE);
Image image2 = new Image(0, "Javaone Keynote", "B", 0,
Image.Size.SMALL);
MediaContent content = new MediaContent(media);
content.addImage(image1);
content.addImage(image2);
return content;
}
Now look at JsonSerializer::deserialize():
public MediaContent deserialize(byte[] array) throws Exception
{
JsonParser parser = _factory.createJsonParser(array);
parser.nextToken(); // start object
MediaContent mc = new MediaContent(readMedia(parser));
mc.addImage(readImage(parser));
mc.addImage(readImage(parser));
parser.nextToken(); // end object
parser.close();
return mc;
}
Note that deserialize() assumes that there are 2 images. Suppose create were
changed to add 3 images instead. Then the roundtrip would, at best, discard one
of the images.
Digging in a little deeper, these are supposed to be optional fields (at least
they are marked so in media.thrift). However, the JsonSerializer's
deserialize() assumes that the exact fields initialized in create() will all be
present in the exact order they were serialized (look at findToken()) at
deserialization time.
Does that make sense? Do you agree that this makes the test of the dynamic
serializers more or less invalid?
Chad
