ちょいと思うことあって実験。まあ、観月が重いんでなんとか軽くならないかな〜、と試行錯誤してるわけですが。webで調べても、JavaScriptの効率いい書き方についてまとめてあるサイトとかなかったもので、んじゃ自分で調べてみるかと。
ちなみに、実験環境はPen4 1.6GHz、メモリ256M、Firefox1.0.7です。
正規表現のマッチング処理でsearchとmatchどっちが速いのか、まあ、文字列を返すmatchよりインデックスだけ返すsearchの方が速そうな気がするんですが、とりあえず以下のようなコードを書いて実験。
var str = "a11b2v3v4\nc4v4b43n\n44";
var regexp = /[ab]\d+[cn]/m;
var regexp2 = /[\dn]c/m
var starttime = new Date().getTime();
for ( var i = 0; i < 3000; i++ ) {
if ( str.match( regexp ) ) var t = str ;
if ( str.match( regexp2 ) ) var t = str ;
}
var matchtime = new Date().getTime() - starttime;
starttime = new Date().getTime();
for ( var i = 0; i < 3000; i++ ) {
if ( str.search( regexp ) >= 0 ) var t = str ;
if ( str.search( regexp2 ) >= 0 ) var t = str ;
}
var searchtime = new Date().getTime() - starttime;
マッチする正規表現とマッチしない正規表現を用意して、真偽判定にかかる時間を測定してみました。このコードを10回走らせて、その平均時間を採ったら、
matchtime = 2734msec searchtime = 2756msec
となりました。matchの方が速い時もあれば、searchの方が速い時もありましたが、はっきりいって誤差範囲内。単純にマッチングの真偽判定ならどっち使ってもいいということですね。私は好みでmatchを多用してますが。
DOMプログラミングする時、行儀良くcreateElementしてappendChildするのがいいのか、innerHTMLプロパティをがしがし書き換えるのが速いのか。慣れるとcreateElementで書いた方が可読性も良いので、こっちを使いたいところですが。
ともかく、以下のようなコードを書いて実験。
var doc = window.document;
var parent = doc.createElement( "div" );
var parent2 = doc.createElement( "div" );
var starttime = new Date().getTime();
for ( var i = 0; i < 500 ;i++ ){
parent.innerHTML += "<a href=\"http://www.hoge.net/\">test</a>";
}
var innerHTMLtime = new Date().getTime() - starttime;
starttime = new Date().getTime();
for ( var i = 0; i < 500 ; i++ ) {
var node = doc.createElement( "a" );
var text = doc.createTextNode( "test" );
node.appendChild( text );
node.setAttribute( "href", "http://www.hoge.net/" );
parent2.appendChild( node );
}
var domtime = new Date().getTime() - starttime;
やってることは、div要素の下にガンガンa要素を付け加えていってるだけです。で、例によって10回測定してその平均を採ってみました。
domtime = 492msec innerHTMLtime = 18752msec
……なんですかこの差は。
正直ここまで差が出るとは思いませんでした。恐らくinnerHTML書き換えは文字列をparseしてDOMツリーに反映させるという処理が加わる分、重くなるといったところでしょうか。文字列が長くなればなるほど劇的に重くなっていくと思われます。DOMプログラミングに慣れないうちはinnerHTML書き換えに頼ってしまいがちですが、ちゃんと行儀良くcreateElementから書いてったほうがいいということが良くわかってしまいました。
ただ、ある要素の子ノードを全部取り払いたいという処理を書くときは、
while ( parent.hasChildNodes() ) {
parent.removeChild( parent.lastChild );
}
と書くよりは、
parent.innerHTML = "";
の方が速いようです。
今日リリースしたVer.0.2.0でUIもそこそこになってきたし、そろそろ虹裏に投下して様子見ようかと思ってた矢先に。「合間合間に」に存在を知りました orz
まあざっと使ってみたんですが。うん、私も合間の方使います。どうしようか悩んでた古いレスNoの自働削除も実装されてるみたいだし。赤福との相性もこっちの方がいいだろうし。
観月の方はバグフィックスは続けます。あと、現時点で上手く行ってないトグル機能と語句置換機能の実装あたりまでは、勉強も兼ねてやってみようかなと。
しかし、虹裏で既に観月の存在を知ってるひとがいたのはちとびっくり。やはり「」は侮れん。
とりあえず、メッセージはlocaleに移したし、ID、IP板対応もしたし、やっつけだけど編集機能も付けたしで、一応、あと0.1.*でやることはバグフィックスだけということになります。次に考えてる仕様変更は0.2.*でということで。
しかし。
やっぱ重いかな〜重いよな〜ちょいと重いような気がする。なんつーか、ひょっとしてlocalstore.rdfを太らせたらfirefox全体のパフォーマンスに影響するんじゃないかという気もしないでもないし。この辺は調べんといかんかもしれん今後の宿題ですな。むー。
そんなわけで、観月専用ページを作ってみたわけですが、牙の人様にて紹介していただけました。ありがとうございます。
というか補足早すぎです。何故にうちみたいな辺境サイトの情報を即日発見できるのか。
で、本日の観月ですが、意味も無くスピグラ板に対応してみたり、データ構造をちょっと考えてみたり、TargetAlert→観月の順番でインストールするとTargetAlertがエラー出して困ってみたり、やっぱり観月重いかな〜と悩んでみたり。
NGワードの仕様についてちょっと考えてて、正規表現対応にするのは割と簡単なんですが、そうしたところでさほど嬉しくないような気がします。が、and条件でNGワード指定したり、名前欄のみに反応するNGワードとか出来たら嬉しいかもしれない。これも機能の実装自体はそんなに難しくないと思うんですが、インターフェース考えるのがどうしよう。
虹裏で使用されることを考えると、アスキーアートがNGワードに指定されることも当然考えられるわけで、ということは“*”とか“|”とかがNGワードに含まれる可能性が高いと。一覧画面でエスケープキャラが頻繁に現れるのは、普段から正規表現とかとお友達の人ならともかく、普通の人にとっては美しくないよな〜。
まあ、そんなことをつらつら考えてるだけで、進展はほとんど無かったりします。というわけで。
本日の観月： なし
観月に設定パネルが付きました。これでXULアプリらしくなってきたかな？
登録したNGワードも設定パネルから削除できるようになったので、大分便利良くなったと思います。これを機にバージョンも一気に上げて0.1.0に。おお、なんかすごい。
ただ、以前のバージョンではNGワードをテキストファイルにベタに保存していたのを、今回からRDFに保存するようになったので、前バージョンで登録したNGワードは使えなくなりました。移行ツールも作れば作れるような気もしますが、まあ需要は無いでしょうね。作るのめんどくさくもあるし(^^;;;
RDFの読み書きについてはTargetAlert（大阪弁ロケール版はこちら）とSwitchProxyを大変参考にさせていただきました。パクったと言うかもしれません。RDF周りはほんと分りにくいのよ(TT)
今後の課題は、メッセージとかをlocaleに移して国際化対応（これは今バージョンでするつもりだったのに何故か上手くいかない）とか、NGワードの編集の実装とか、今のところNGワードに正規表現のメタキャラを含めるとえらいことになる気がするのでその辺をなんとかするとか。あとバグ出しですね。まあ、使う人もあんましいないと思うのでのんびりいきますか。
もし使ってくれる人がいたらバグ報告とかしてくれると嬉しいかもです。
本日の観月： ver 0.1.0 mitsuki_0.1.0.xpi
追記：赤福のメル欄表示機能との相性がよろしくない気がします。赤福の機能はあまり把握してないのでちょっと調査する必要がありそう。
あいや、firefox版赤福にメル欄表示機能が追加されましたね。ということで、先日のメル欄表示スクリプトはあっさりお役御免です。早かった……orz
気を取り直して。
今作ってるのが、登録したNGワードを含むレス／スレッドを見えなくするという、まあ2ch風に言えばあぼーん機能の虹裏版ってやつです。今のところ、
といった機能を実装してます。
今のところNGワードの編集・削除が、直接プロファイルフォルダにあるkilllist.txtを弄るという手段しかないので、これは早めに何とかしたいところ。文字スレ、赤字スレの表示／非表示も設定できた方が便利だろうし、多分左フレーム表示状態だと上手く機能しないだろうし、削除済みのレスがダブルクリックで表示できたら便利かもしれないとかいろいろ考えてはいるんですが。まあ、のんびりと作っていきたいところ。
本日の観月： ver 0.0.1 mitsuki_0.0.1.xpi
Greasemonkeyというものを知ったのでちょっといじってみる。
要するにコンテキストメニュー拡張（CME)にあったカスタムスクリプト機能だけ取り出したもの、と考えればよいらしい。CMEだとちょい重かったり、導入、設定がめんどかったりと、折角スクリプト書いても他人にすすめにくかったのですが、Greasemonkeyだとユーザスクリプトのインストールも簡単なのでこりゃいいわと思った……のですが。
Greasemonkey上からだとXPCOMが使えないじゃーん(TT)
ということはローカルファイルの読み書きが出来ないということで、一気にやれることが減ってしまいました。とほほ。セキュリティ上なんでもやれるのはまずいから、ということなのかなあ。けどCMEで出来たことは出来てほしいなあぶちぶち。
まあそれはともかく、折角なのでちょこっと書いたスクリプトをひとつ。元々はCME用に書いたスクリプトを移植しただけですが。
ふたば虹裏用のメール欄表示スクリプトです。いや虹裏でなくてもふたば全般で使える……はずです。一応、img、dat、may、ネッキャラ、甘味辺りで動作確認したので大丈夫だと思いますが。
双助とかやよねなあたりを使ってたら必要ないのかな？
追記：
Greasemonkey Compilerを利用したxpi版も作ってみました。Greasemonkeyをインストールするのがめんどい人はこちら。
GUIDジェネレータがなんかなくなってるぽいので、ここのGUIDGENを利用してみました。