2009年1月13日火曜日

Google Chromeが速いわけ: スピード狂のあり方

@ITにGoogleのブラウザ「Chrome」に対する開発者のスピード狂ぶりを綴った記事が出ていました。

この記事によると、Webサービスにおいては0.5秒遅いだけでユーザが離れていくそうです。その教訓から、Chromeには徹底したスピードへのこだわりを終結させており、その結果としてあの素晴らしいレスポンスが得られるようになったわけだそうです(私が使っているような低速なPCではそれほど激早というわけではないですが)。

個人的にはプロセス分離やドメイン先読みはやりすぎなような気がしますが、他のブラウザがやらない(できない)ことをしている、という点では面白いと思います。

開発者は皆、多かれ少なかれスピード狂です。私はそれほどスピード狂ではないですが、応答性を高めるためにスレッドを分けるとか、ファイルからのI/Oを極力減らすとか、データの先読みをする、という点は常に気をつけるようにしています。

一方でメモリ使用量も抑えるように色々考えています。スピードとメモリ使用量はトレードオフですからね。例えば10万パケット入っているキャプチャファイルに対して、全てのパケットの開始位置(uint)をリストにするだけで400KB必要です。タイムスタンプと発着IP/Portも一緒に保存したら3MBぐらい必要になります。

スピードのためにメモリを大量確保するのか、それともスピードを犠牲にしてメモリ使用量を抑えるのか、もしくは両方とも折り合いのつく着地点を探るのか、開発者はいつでも葛藤しています。Googleの中の人は相当苦労したと思います。それともノウハウたくさん持っているからそれほど苦労せずに見通しが立つのでしょうかね。うらやましい。。。

2009年1月1日木曜日

[WireWhale]激早!! FileStreamのPosition、Length→自前で保持

今までキャプチャファイルの読み込みはFileStreamからPositionプロパティを使ってせっせと読み出し、Lengthプロパティの位置まで来たら止める、という方法をとってきました。これだと50MBのキャプチャファイルを読み出すのに大体10秒ぐらいかかっていました。

Wireshark(というかcapinfo.exe)でキャプチャ情報を読み出すのも大体それぐらいかかっているので、それが普通かなと思っていました。が1ファイル開くのに10秒も待っていられない! 何とかならないものかと試行錯誤していました。

そんな中、CodeProjectにFast Binary File Reading with C#という、ストリームの読み込みの手法毎の性能比較の記事があったの でWireWhaleもチューニングしてみました。具体的には、PositionLengthプロパティの使用を極力減らし、値は変数で保持、Positionを移動するときはSeekを使うようにしてみました。

結果、、、びっくり!!! 何と50MBのキャプチャを開くのに5秒かからなくなりました!!! プロパティ内で何してるんでしょうね!?

やっぱりこういう細かい調整が性能を大きく左右するんですね。とても参考になりました。

参考
Fast Binary File Reading with C#