メモ: ベンチマークツール jvm-serializers
- jvm-serializers https://github.com/eishay/jvm-serializers/wiki
ツールメモ 兼 プチコードリーディングメモ。
MessagePackのWikiを眺めていて知った、Javaのシリアライズ/デシリアライズのパフォーマンスを測定するツール。
以前からあったTPC（Thrift-ProtocolBuffer-Compare）が、このプロダクトになったようです。
結果のグラフ表示もしてくれます。ベンリかな？
ナノタイム？？
公式に次のように書いてあり、
Times are in nanoseconds, sizes are in bytes.
某谷先生のブログにもこう書いてありました。
全てナノタイム計算なので、上位五位くらいまではほぼ誤差の範囲内で問題ないと思います。
時間計測に興味があるので（参考※JDKの時間計測まわりのコードを読んでみる http://d.hatena.ne.jp/torazuka/20110227/jdk）、もしかして何らかの方法でナノタイムの取り方が書いてあるのかしらん？と期待してコードを読んでみたのだけれども、案の定、System#nanotimeを呼び出しているだけで、ガックシ。そりゃそうか。
はんどしりあらいず？？
見晴らしの良いコードなので、java.io.DataInputのJavaDocをおともに、読んでみる。
読みやすいけど、何をやっているかわからない・・・。
特に、手でシリアライズ・デシリアライズしている、とされる部分。JavaManual.javaでImageクラスとMediaクラスを読み書きしているところ。
たとえばImageクラスは、titleやwidthやheight等のさもImageらしい（？）フィールドを持っています。しかし、ストリームからreadIntした値を、直接ガシガシwidthフィールドに突っ込んでいます。えっそこ？？ｗｗ Imageクラスのwidthって、なんかもっと違うものかと思ったヨ・・・というカンジ。何だこりゃ。
で、どこぞに相談したら、こりゃシリアライズ・デシリアライズが高コストになるように（テストのために負荷をかけやすくした）独自のImageとかいうオブジェクトを読み込んでるんじゃね？、と教えてもらいました。
なるほど。ありがとうございます。
（追記） それぞれのライブラリの作者にテストコードを書いてもらったら、もっと違った結果になるんかもしれませんね。極限まで性能を搾り出す的な。
