博士

ロボ子、今日はRavenDBのパフォーマンス改善の話じゃ。なんと、15年間もパフォーマンスを改善し続けているらしいぞ。

ロボ子

それはすごいですね、博士。15年間もですか！

博士

そうなんじゃ。専門チームがボトルネックを見つけて修正しているらしい。CPUマイクロコードレベルでの設計もするらしいぞ。すごいじゃろ？

ロボ子

CPUマイクロコードレベルとは、かなり深いところまで手を入れているんですね。

博士

今回、ドキュメントのシリアライズ時にLINQ式をコンパイルしていたのが問題だったらしいんじゃ。これは無駄な処理だったみたい。

ロボ子

LINQ式のコンパイルですか。それがパフォーマンスに影響していたんですね。

博士

修正前は33,782ミリ秒かかっていたのが、修正後は20ミリ秒になったらしいぞ。なんと1,689倍の高速化じゃ！

ロボ子

1,689倍！それは劇的な改善ですね。

博士

この問題、実は表面化しにくかったらしいんじゃ。コードがグローバルではなくインスタンスごと、かつスレッドごとに一度だけ実行されるからじゃと。

ロボ子

なるほど。スレッド数がほぼ固定されている状況だと、問題が顕在化しにくいんですね。

博士

そうなんじゃ。スパイクが発生してスレッドが頻繁に生成・破棄される場合に問題が顕在化するらしい。ロードスパイク時にスレッドプールが新しいスレッドを発行して、CPUを無駄に消費してしまうんじゃ。

ロボ子

ベンチマークでは明確な改善が見られないかもしれないけれど、スパイク時のCPU消費を抑えることができるのは大きいですね。

博士

そうじゃな。RavenDBの品質向上に貢献する重要な修正じゃ。このコード、2017年から存在していたらしいぞ。

ロボ子

2017年からですか。長い間潜んでいたんですね。

博士

まさに「事実は小説より奇なり」じゃな。しかし、ロボ子よ、1689倍速くなったところで、私のカップラーメンができる時間は変わらないのが残念じゃ。

ロボ子

博士、それはRavenDBとは関係ありません！