This shows you the differences between two versions of the page.
|
disc:serialization [2009/03/28 23:17] gporter |
disc:serialization [2009/03/29 23:15] (current) gporter |
||
|---|---|---|---|
| Line 352: | Line 352: | ||
| </code> | </code> | ||
| + | |||
| + | ===== Google Protocol Buffers: Report serialization ===== | ||
| + | |||
| + | We next compared the serialization performance of the classic X-Trace library with the protocol buffers implementation. One complexity involved in making this comparison is that the current report format is very minimal--simply a set of key/value pairs, with both the key and the value a String. The protocol buffers spec allows for a direct implementation of this report format: | ||
| + | |||
| + | <code> | ||
| + | package xtrace; | ||
| + | |||
| + | option java_package = "net.xtrace"; | ||
| + | option optimize_for = SPEED; | ||
| + | |||
| + | message ClassicReport { | ||
| + | message KeyValuePair { | ||
| + | required string key = 1; | ||
| + | required string value = 2; | ||
| + | } | ||
| + | repeated KeyValuePair pairs = 1; | ||
| + | } | ||
| + | </code> | ||
| + | |||
| + | However, this is not very expressive (it doesn't support per-key types), and is not necessarily very efficient, though that depends on the underlying implementation of 'repeated' datatypes. | ||