Avro seems to be sliding a bit in this benchmark. The poor "create"
time has always been a problem for Avro, although I'm not sure why.
This isn't a great benchmark, but lots of folks look at it, so it'd be
nice if we did well there.
Doug
-------- Original Message --------
Subject: New benchmarking page.
Date: Thu, 22 Apr 2010 04:34:04 -0700
From: Kannan Goundan <kan...@cakoose.com>
Reply-To: java-serialization-benchmark...@googlegroups.com
To: java-serialization-benchmark...@googlegroups.com
I've created a "version 2" of the Benchmarking page.
http://code.google.com/p/thrift-protobuf-compare/wiki/BenchmarkingV2
These measurements were generated using the new code I've been adding
over the past month or so. One advantage of the new code is that I've
actually tried to make the various serializers do the same amount of
work (previously, many serializers were specialized to the exact data
value being tested).
A couple notes:
1. The timing measurements aren't very precise. I tried taking the
best of 100 trials (instead of the default best of 20) and the numbers
still won't stabilize. I sometimes get a 20% difference between runs.
A side-effect of this is we sometimes end up with weird results like
the "deserialize" time being greater than the "deserialize and access
fields" time.
2. The Scala object creation times are higher than before. I think
this may be because I rewrote the Scala code and used "Option[T]" in a
couple places that were previously just "T". Most of the Java-based
tools just use "null" for optional values, which is more efficient.
3. The "java (externalizable)" test didn't look like it was using the
Externalizable feature of Java at all. I renamed it "java-manual"
since all it does is manually serialize using a DataInputStream and
DataOutputStream (which is basically what Kryo does with runtime code
generation).
4. Do you think it's useful to have the XML/JSON tests that use
abbreviated field names? You'd think someone would use XML/JSON over
a binary format for readability; using abbreviated field names negate
that advantage (partially).
5. I use a slightly different data value (intended to be a bit more
realistic). See the wiki page: DataStructuresV2.
-- Kannan
--
You received this message because you are subscribed to the Google
Groups "java-serialization-benchmarking" group.
To post to this group, send email to
java-serialization-benchmark...@googlegroups.com.
To unsubscribe from this group, send email to
java-serialization-benchmarking+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/java-serialization-benchmarking?hl=en.
