2008年5月30日金曜日

Safariのメモリ使用量を取得する実験を、"半"自動化してみた。

先日の「Safariのプラグインを導入していくと重くなるorならない?」で、いくつか実験を行いました。お恥ずかしながら「② メモリ使用量の比較」では、ずっとアクティビティモニタとにらめっこしてました。

本当は、スクリプトから自動的にデータを取得していく予定だったのですが、あの時は「新規タブ」を開く方法が分からなくて断念しました。その後、ちょっとトリッキーな方法なのですが、「新規タブ」を開く事が出来るようになったので、実験を自動化してみました。

作ってはみたものの、使う機会は無いだろうな〜と思っていたら、OS X 10.5.3がリリースされ、Safariのビルド番号も上がったので、データを再取得してみました。その結果が↓です。


↑前回と同じようなグラフになりました。(3次より2次の方が分かりやすかったので変えましたw)


結論も殆ど変わらないのですが、私の利用している環境では、プラグインを導入すると
  • 起動時に3MB程度のメモリ使用量が増えている
  • 1つタブ開くごとに700〜800KB程度増えていく
という結果になりました。やはり、得られるメリットを考慮すると全く問題無いレベルだと思います。


ちなみに、このテストの自動化には、RubyとRubyOSAを利用しています。(AppleScriptは知らないので...)RubyOSAは「gem」から簡単に導入する事が出来ます。→「sudo gem install rbosa」

後は、以下のスクリプトを実行すると、ターミナル上にメモリ使用量がポツポツと表示されていきます。("全"自動じゃないのは、プラグインの着脱やデータの加工が手動だからですw)

また、スクリプトを実行する前に、Safariの「環境設定...」→「タブ」→「タブおよびウインドウ作成時に、選択された状態にする」にチェック入っている事を確認して下さい。

require 'rubygems'
require 'rbosa'

#実験で使うURLリスト
urls = %w(
http://www.google.co.jp/
http://www.yahoo.co.jp/
)

#Safariを起動する
`open /Applications/Safari.app`

#RubyからSafariを操作できるようにする
OSA.utf8_strings = true
app = OSA.app('Safari')

urls.length.times{|i|
#新規タブを開く
#openメソッドは、ファイルしか開けないようなので、一度空ファイルを開くようにした
app.open('/dev/null') unless i == 0
#URLリストからページを開く
app.documents[0].url = urls[i]
#スリープする(ページの読み込みを待つ)
sleep(10)
#psコマンドからSafariのメモリ使用量の取得し、MB単位でターミナルに表示する
puts `ps aux | grep [S]afari`.split()[5].to_f/1024
}

#Safariを終了する
app.quit

このスクリプトでは利用しなかったのですが、「sourceメソッドでページのソースを取得」→「Hpricotでパース」→「do_javascriptメソッドで操作」という事もできそうです。もしかしたら、Webサイトのテストツールとしても利用できるんじゃないか!?と思っています。もし使う機会があったら、また紹介したいと思います。

6 件のコメント:

  1. ちょうど僕もRubyOSAを使っているところです。
    僕もAppleScriptがわからないので使っています。

    僕はiTunes内の壊れているファイルを再度取り込む時のためにまとめてリスト化しようとしてました。
    イマイチのできでしたw
    みんなファイル壊れないんですかね?

    返信削除
  2. こんばんは!

    壊れるって音楽ファイルがですか?
    今のところそのような経験は無いのですが、
    単に気付いていないだけかもしれません...。
    あ、ライブラリなら壊した事ならあります!w

    返信削除
  3. はい。音楽ファイル自体が壊れてるんです。
    例えばあるアルバムの3曲目が聞きたくてそれをダブルクリックして再生しますよね?
    普通ならその曲が再生されるのですが、そのファイルが壊れていると再生に失敗?して自動的に次の曲が再生されます。もし次も壊れていたらまた次の曲といった感じで、アルバム12曲中2曲目を再生しようとしたら結局再生されるのは10曲目とかになってしまいますw
    そんなのが僕の40Gくらいのライブラリに結構紛れてるんです。それをいかに楽してリストアップして修復するかが僕の課題です。

    返信削除
  4. むむむ、それは結構厄介ですね...。
    幸いにして、私の環境では遭遇した事が無いです。

    スキップされた曲って、再生回数(played_count)や最後に再生した日(played_date)等も更新されていくのですか?何か正常なファイルとの違いがあれば、とは思ったのですが...。

    詳しい状況が分からないので、余りお役に立てそうに無いです。もしよければ、「連絡先」へ壊れたファイルを送って貰えれば、一緒に悩むことろまではできますよw

    返信削除
  5. > スキップされた曲って、再生回数(played_count)や最後に再生した日(played_date)等も更新されていくのですか?

    すばらしいヒントを頂きました。
    これをチェックしてみると、スキップされた曲(再生できなかった曲)は”最後に再生した日”が更新されます。
    通常、曲の最後まで再生しないと”最後に再生した日”は更新されないというのを利用してこんな作戦にしました。
    iTunesMSPを使って再生時間を3秒(3秒未満の曲が存在しない事を期待)に設定。
    ライブラリ内の全曲をこれで再生。
    数時間放置。
    一巡したら、スマートプレイリストで今日再生した曲だけを集めると壊れた曲だけ(ほんの少し違うのも混ざりますが)のプレイリストができるのでプリントアウトして完成。

    5438曲中396曲が壊れている様です。
    容量にして2.5G程度です。

    これからの問題はCDの発掘ですw

    すばらしいヒントありがとうございました。

    返信削除
  6. なるほどー。これならスクリプト使わずに確認できますね!

    気になったので、私の環境でもチェック(放置)してみました。10秒程度の曲は「再生」になりましたけど、それ以外は抽出されませんでした。おそらく、全ファイル無事だと思われます。まあ、母数が少ないだけかもしれませんけど。

    次なる課題は物理ディスクを探し出す事ですね!こちらの方が大変そうですw

    返信削除