@IT に「Chromeはなぜ速いのか」という記事が出ています。インターネット ブラウザを作る上だけではないノウハウが満載なので、簡単にまとめておきます。→そんなことない？
Google Chrome の応答性へのこだわり
- プロセスは、大きく3種類のプロセスを生成する。
- ユーザー インタフェース
- レンダリング
- プラグイン
- 起動プロセスは、できるだけ簡潔に行う。
- 最初に読み込んでいるのは、chrome.exe と chrome.dll、設定ファイルだけ。ページのレンダリングに必要なモジュールやその他もろもろは後から非同期に読み込む。驚くべきことに、ネットワーク関連のモジュールさえも読み込んでいない。
- ユーザーがアクセスするプロセスからのディスク I/O は一切禁止。
- 子ウィンドウを作らせない。
- 子ウィンドウがあると、Windows メッセージの仕組み上、どこかのウィンドウで処理がもたつくと、全体の応答性が低下してしまう。
- レンダリング プロセスは本体ウィンドウへの描画を間接的に行う。
- いったん裏画面へ描画し、表画面へ転送する（もちろん必要に応じて、だと思う）。
- Chrome ブラウザは、フィッシングサイト対策のために URL リストを保持するが、URL そのものではなく、SHA-256 値を持っている。
- しかも、SHA-256 値は、256 bit のうち先頭の 32 bit だけである（32bit がヒットしたら、Google のサーバーから本当に疑わしい URL なのかを確認しにいく）。
- URL → IP アドレスへの変換（DNSによる名前解決）をユーザーからの命令（クリックなど）が来るまでもなくやってしまう（AJAX的だ）。
応答性へこだわる理由
- 当初のわれわれのGoogle Chromeの目標は、このブラウザをできるだけ速くすることだった。しかし、生の速度（raw speed）に加えて高い応答性を持つようにしたかった。結局のところ、ページがいくら速くロードできたって、ユーザーインターフェイスが固まったら意味がないんだから！ (But in addition to raw speed, we wanted it to be highly responsive. After all, it doesn't matter how fast pages can be loaded if the user interface is locked up!)
- 0.5秒の遅延でユーザー離れしてしまう。
その他
- ユーザーをないがしろにしないこと (not to maltreat users)
- 裏でできる限りのことをやろう
- コード変更のたびに、「自動ビルド→自動テスト→自動パフォーマンス計測」され、パフォーマンスが悪くなるようなコード変更は許さない。
以上
追記＠2008-12-24T08:53
そういや最近、自分が書く GUI のツールは、「コンソール呼び出し」が多くなってきました。コンソール呼び出しの場合、UI スレッドとは完全に分離されているので応答性が良いですし、結構 Chrome さんに似ている感じになっています。ま、でも呼び出す先のプロセスはひとつのコンソールなんで、Chrome さんのように、レンダリングプロセス、プラグインプロセスのようにヘテロジニアスな感じではないですが。ま、似てますね。