Ah, gotcha.
On May 12, 2009, at 9:59 AM, Chad Walters wrote:
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
