Adobe AIR (Linux) のHTMLLoaderが遅い - 駄目だこいつ…早くなんとかしないと

2009/06/06

パーマリンク 19:24:14, 著者: Charlie

Adobe AIR (Linux) のHTMLLoaderが遅い - 駄目だこいつ…早くなんとかしないと

Adobeが提案しているAIRに含まれているHTMLLoaderは、Googleの高速ブラウザChromeでも使われているWebKitというエンジンを使っています。 また、JavaScriptのベンチマークもそこそこ速いという結果が出ており、プログラマの良い箱庭になりそうな期待を抱かせます。

ところが実際にこれで簡易ブラウザを作ってみると、なんだかもっさりとしているのです。特にLinuxで動かした時、ページのレンダリングがなかなか完了しません。 Firefox 2で10秒くらいかかるページは、AIRだと1分近くCPU負荷100%の状態が続きます。

一体何が足を引っ張っているのか……疑問に思ったので調べてみると、何とも冗長な処理が見付かりました。

[◇◇◇]

cookieの変更のたびにファイルを何回もロックしている

cookieの処理がとんでもないことになってます。straceコマンドでシステムコールを追跡すると、HTTPのGETリクエストが処理されるまでの流れは次のようになっていました。

  1. ~/.appdata/cookie_file.txt をopenして、排他ロックで読み取る。
  2. ~/.appdata/cookie_file.txt を空(O_TRUNC)にして排他ロックで書き出し。
  3. ~/.appdata/jrcf_**** を空にして書き出し。
  4. ~/.appdata/jrcf_**** をopenして読み取る。
  5. GETリクエストを送信してpoll。
  6. レスポンスを受信。
  7. ~/.appdata/jrcf_**** を空にして書き出し。
  8. ~/.appdata/jrcf_**** をopenして読み取る。
  9. ~/.appdata/cookie_file.txt をopenして、排他ロックで読み取る。
  10. ~/.appdata/cookie_file.txt を空にして排他ロックで書き出し。
  11. ~/.appdata/jrcf_**** を削除 (unlink)。

以上の処理を、GET/POST 1回ごとに行っているようです。例えば画像やらJavaScriptやらCSSを10個読み込んでいるページでは、レンダリング中に10個のリクエスト分のスレッドが順次生成されて、一つのファイルに対して合計40回の待ち合わせをしながら同じような内容を書いては消すのを繰り返しているわけです。効率が悪すぎますね。

Fxはどうしてるか

参考までにFirefox (Fx)のcookie処理を調べました。

  1. リクエスト毎ではなく起動時にcookies.txtを読み取る。
  2. リクエストごとの読み書きはメモリ上のキャッシュに対して行う。
  3. 書き換えは終了時にまとめて。(一時ファイルに書き込んで rename)

Fxのcookie読み書きには、ファイルに対する排他処理が存在しません。 クラッシュすると、その間の変更が失われてしまう恐れはありますが、そもそもcookieはUAが勝手に忘れても構わないもの扱いなので大したリスクではないでしょう。

また、AIRではHTTP 1.1のkeep-aliveを使わず一度に沢山のセッションを張っている感じ。 しかも同じ画像ファイルが1ページ中に複数回使われていた時に、Fxは当然ローカルキャッシュを参照しますが、AIRは複数回リクエストを投げています。 AIRアプリでHTMLLoaderのキャッシュ機能を有効にしているのですが、このような挙動ということはそもそも未実装なのでしょうか?

対策実験・cookieのファイルをon memoryにしてみる

原因らしきものが分かったところで、高速化できるか考えてみました。 「cookieの情報がメモリ上にあれば、速くなるのでは?」 HDDをSSDに置き換えるとシステムが速くなるのと同じ理屈です。

早速、次のようにして試してみました。
mkdir /tmp/appdata
mount -t tmpfs /dev/shm /tmp/appdata/
mv ~/.appdata ~/.appdata.org
ln -s /tmp/appdata ~/.appdata
cp -a ~/.appdata.org/* ~/.appdata/

この後、AIRのHTMLLoaderを使ってみると……あまり速くなったようには感じません。 ベンチマークをしてみました。ウィキペディアのメインページなどを表示して描画完了までの時間を手動計測します。ぶれが大きいので3回の平均を取りました。

描画速度の比較グラフ

確かに3〜5秒程度の時短を達成しているので、効果はあります。しかし、Fxと比較するとまだまだお話にならないのでした。

実験のまとめ: 速くはなるが、焼け石に水

関連記事

この記事へのトラックバック アドレス

http://blog.mura.com/blogs/htsrv/trackback.php/1089

コメント, トラックバック, ピンバック:

この投稿への コメント/トラックバック/ピンバック はまだありません...

コメントを残す:

頂いたメールアドレスはこのサイト上には表示されません
頂いたURLは表示されます。

使用可能な XHTML タグ: <p, ul, ol, li, dl, dt, dd, address, blockquote, ins, del, span, bdo, br, em, strong, dfn, code, samp, kdb, var, cite, abbr, acronym, q, sub, sup, tt, i, b, big, small>
(改行が自動で <br /> になります)
(名前、メールアドレス、URLを記憶する Cookie を発行します)
(ユーザがメッセージ・フォームを通してあなたに連絡することを許可します (あなたのメール・アドレスは表示されません))

Charlie's volatile short

7月 2010
 << <   > >>
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

リンク

  • ありくい - ブログが手軽に書けます。ボタン一つでコンテンツマッチ・アフィリエイトが挿入できるブログツール「どこでもありくい」も提供中。
  • glucose2 - ブログをたくさん読むならRSSリーダー
  • エンジニア募集中 [Perl, PHP, JavaScript][SOHO, アルバイト可]

  • ブログ之ネタ [ブロガー御用達ポータル]

  • rico [PV改善,サイト内SEO,ブログパーツ]

アーカイブ

検索

いろいろ

XMLフィード

RSSとは?

オンラインユーザ一覧

  • ゲスト ユーザ: 6

powered by
b2evolution