JavaScript::SpiderMonkeyを試してみた

先週末くらいから、今さらかもしれませんがJavaScriptにはまっています。
Ajaxとかじゃなくて、割と純JavaScriptなんですけど、いやあ結構おもしろいですね。
まだ恥ずかしながらプロトタイプベースのオブジェクト指向とか十分に理解しているわけじゃないんですけど、ぼちぼちいろいろ試しています。

今メインでやっているのが、色んな地図サイトななんかで同じ位置情報を表すURL間の相互変換です。
各サイト間の変換情報をハッシュテーブルで持つ際に、どうしても一部クロージャでロジックそのものをテーブルに持たざるを得ない状況です。
で、同じ処理をサーバサイドでもやる必要が生じたんですが（Mappletとかグリモンとか、携帯サイトとか、いろんな形で同じ機能を提供するため）、変換テーブルをJavaScript用とPerl用の2つ持って両方メンテナンスするというのはいかにも面倒くさい。
そこで、その部分だけJavaScriptで処理したったらええんちゃう？と思って、SpiderMonkeyとJavaScript::SpiderMonkeyモジュールを導入してみました。

インストールは超簡単。
こちらの記事で取り上げられている通りにするだけで、手順的にも時間的にも簡単にできました。
大体この手の導入って、過去の経験上、導入記事に簡単に書かれていても一悶着二悶着あるものと身構えていたのですが、本当にあっさりと。
ただうちの場合、CVSは使ってないのでtarballをこちらから落としてきたことくらい。
テストも問題なく通り、拍子抜けするくらいでした。

ただ、「その部分だけJavaScript処理」といっても、他言語の処理環境を走らせるわけだし、処理が重くなる度合いが度を越えていたら使えないので、ちょっと実験してみました。
JavaScript::SpiderMonkeyでの処理を含んだFastCGIスクリプトを実行した際と、同じ処理をPerlにやらせた際の処理速度の比較。
試したのは、

• FastCGIループの外でJavaScript::SpiderMonkeyのオブジェクトを作って、JavaScript実行
• アクセスの都度JavaScript::SpiderMonkeyのオブジェクトを作って、JavaScript実行
• Perlでeval実行
• Perlでハードコーディングしての実行

んで、PerlとJavaScriptで、同じ内容で同じ処理をするプログラムとして、n9dさんのFizzBuzzコードを少々改題したものを使いました。
コード的にはこんな感じ。

#!/usr/bin/perl

use CGI::Fast;
use JavaScript::SpiderMonkey;

my $js = JavaScript::SpiderMonkey->new();
my $code = 'for($i=1;$i<=100;$i++){print_to_perl($i%15?$i%5?$i%3?$i:"Fizz":"Buzz":"FizzBuzz");}';

while (my $q = CGI::Fast->new) {
    print "Content-type:text/html\n\n";

    my $p = $q->param("mode");
    if($p !~ /[0-3]/) {
        print "Error!";
        next;
    }

    if ($p < 2) {
        my $ljs = $p ? JavaScript::SpiderMonkey->new() : $js;
        $ljs->init();
        $ljs->function_set("print_to_perl", sub { print "@_<br/>"; });
        $ljs->eval($code);
        $ljs->destroy() if ($p == 1);
    } elsif ($p == 2) {
        eval($code);
    } else {
        for($i=1;$i<=100;$i++){print_to_perl($i%15?$i%5?$i%3?$i:"Fizz":"Buzz":"FizzBuzz");}
    }
}

sub print_to_perl { print "@_<br/>"; }

これでApacheBenchで1000回アクセスして実験してやると、こんな感じになりました。

うーん、やっぱり歴然とした差がありますねえ…。
秒あたり1アクセスとかみたいに死ぬほど遅いってわけでもないですが、せっかくFastCGIで動かしてるのがCGI並みの処理能力になってしまう...。
かといって、やっぱ変換テーブル2重持ちの管理コストも結構なもんだし...。
死ぬほど遅かったりしたらすっぱりあきらめられるところなんですが、微妙な線だけに悩めるところです。