えちょ記

語らないブログ

SHIOLINKのオーバーヘッドについて

うかべんで質問を受けたんですがきっちり答えきれていないと思ったので。

Q: SHIOLINKは十分なスピードで動作しますか?
A: わかりません。

いや、もうしわけないです、ごめんなさいこれはSHIOLINK的には回答できませんorz。というのも、実質のオーバーヘッド要因はSHIOLINKの先につなぐプログラムしだいだからです。
まずSHIOLINKそのものは重いのかというと、恐らくオーバーヘッドを感じるほどの負荷は発生していないはずと考えています。

SHIORIリクエストでもっとも重いのは起動処理イベント

会場では「マウスイベントが処理できるのか?」という話が出ていましたが、実はSHIORIにおいてもっとも重いイベントはマウスイベントではありません。SHIORIログを見たことがあれば分かるかと思いますが、「初期起動トーク」が発生するまでに立て続けに発生する起動処理イベントがもっとも重い処理となります。つまりゴーストが重いかどうかは、ゴースト切り替えから実際にしゃべるまでがどの程度重いかで大体推測できます。
その観点で言えば、少なくともSHIOLINK付属ゴーストの起動は十分早いほうです。シェルも1枚絵なので当然とはいえますが(^^;。SHIOLINK自体はリクエストのパイプ通信への変換だけですし、起動しているのもWindowsXP付属のcscript(JavaScript/VisualBasicScriptのエンジン)なので、起動は早いです。

SHIOLINK自体は目に見える負荷要因とならない

ゴーストエンジンが重いかどうか、という設問において、SHIOLINK自身の負荷決定要素は大きくはありません。確かにSHIORIリクエストを標準入出力通信へ変換する過程におけるオーバーヘッドは存在します。しかし、その変換負荷は、そのリクエストを受けて実際にゴーストの会話を組み立てるエンジン側が行う必要のある演算量に比べれば、実測できるほどの優位な差が発生する要因になるわけではありません。

汎用言語エンジンは十分に早い

さて、SHIOLINKを使いたい、という人が使う呼び出し側のエンジン本体は、有名どころの汎用スクリプト言語か、あるいは.NETでしょう。C言語などで自力でエンジンを組める人がSHIOLINK使う意味無いですからね(^^;。また.NET連動もSHIORI的に理由があるので、.NETでSHIORI作りたい場合の選択肢にもなりえます。
汎用スクリプト言語、列挙してみるとなでしこ、cscript、rubypython‥‥など。SHIOLINKは早いか?という質問は、最終的にはこれらの汎用スクリプト言語と、従来の栞エンジンとどっちが早いのか?という質問に帰着します。
選択するエンジン次第なので重いエンジンなら重いんですが(^^;、自分が知ってるpythongoogleなども開発に加わっている事から、インタプリタ型エンジンとしては非常に早い部類です。恐らく言われない限り、エンジン内部がSHIOLINK+スクリプト言語だということはばれないくらいの速度で動くと想定しています。

結論

とここまで書いても、結局のところSHIOLINK単体としては「SHIOLINK自体が負荷要因とはならないと思います」としか言いようがありません。この辺突き詰めると、そもそも素のSHIORIインターフェース自体、非常に重い実装なので、SHIOLINKで重い状況ならほかの栞でも同様に厳しい状態になります。

雑感

個人的には、SHIOLINK自体は楽に栞を実装するための1手段と認識しています。1から栞を組みたい人の動機はそれぞれでしょうが、その人にとって使い慣れた汎用のスクリプト言語をつかって栞を作れるというのは大きなアドバンテージじゃないかと。また、SHIOLINKは、多分スクリプト言語をSAORI universalにする手段にもなりえますので、もしかしたらそちらの用途の方が重宝されるかもしれませんね。