最新版:String Tokenizer バーサス 自作エクステ/処理速度対決


勝負だ!!だが悪いな、今回も負ける気はしねぇ。

stringTokenizer_VS_GArR_s

というわけで、ユニコード処理に対応した最新版の「String Tokenizer」と prester.org で自作した公開予定のエクステ「 GArR (ガー)」が夢の直接対決実現。

前回の戦いでは GArR が圧倒的勝利でしたが、ユニコードに対応した本家 String Tokenizer がリベンジを挑んできました。もはや言語の壁は存在しません。止まない進化・暑い戦いの行方は新たな次元へ…!

参考:String Tokenize 機能、速度比較

まぁ単なる遊びなのですが

とりあえずベンチマーク計測条件は前回と同じ、でも前回よりちょっと詳しい情報などを載せておきます。

まず処理対象となる文字列ですが 30000 Byte のテキストファイル、これを二次元配列化する処理速度を競っています。

前回は String Tokenizer がユニコード非対応だったため日本語(マルチバイト)文字列を含めたテキストは処理させませんでしたが、ユニコードに対応した最新版の String Tokenizer が来たため、今回は日本語文字列も配列化させて結果を比べてみます。

比較のための条件など

ちなみに前回の比較にも使われた英語( ANSI )だけで構成された文字列は配列化すると X Dimention は 1222、総要素数は 5159。これで 30000 byte(30Kb) です。

今回から加えられた新しい日本語を含めた文字列の方は X-Dimention が 402、総要素数は 2310。ちょっとサイズミスったため 30001 byte となっています。

処理内容的には配列要素数が大きい方が負荷は高いため、英語だけで構成された文字列のほうが処理するための時間はかかる=重い処理ということになります。

そしてこれら文字列を 40 回ループ処理させ、完了までにかかった時間を CF25 内部のタイマーを使って時差として計測します。数値が小さいほうが速いということで、基本的に 1 FPS 以内に処理を終えることができる目安となる 16 ミリ秒の近似値を得ることが理想。ちなみに CF25 のタイマーは正確に時間を計測できないためこのようなベンチマークとなっています。

ループ処理に関しては前回よりも少し負荷を高めてテストすることにしました。前回=30、今回=40。というのは追試したら GArR はループ 30 回でもまだ余裕があったらしく、このためループ 40 回からスタートにしました。

そして今回はどちらもユニコード対応なので純粋にロジックの差が処理速度の差となります。

では結果発表

StringTokenizerFunction_TEST02英語文字列の二次元配列化処理
StringTokenizerFunction_TEST02_detailズーム画像#01
StringTokenizerFunction_TEST01日本語文字列を含めた二次元配列化
StringTokenizerFunction_TEST01_detailズーム画像#02

GArR 圧勝

結局ユニコードに対応してもロジックの差があるため、最低二倍程の速さは維持してるみたい。GArR の方が速い。

前回より String Tokenizer も速くなってる気がするけど、ユニコードに対応したことで日本語などを文字化けなしで扱えるようになったのがなによりも大きい。

参考:Extension Manager (エクステンション マネージャー)について

というわけで String Tokenizer のアップデートはエクステンション・マネージャからどうぞ。

なお、本家の String Tokenizer はメモリリークが治ってないからリークしてることに気がついてない模様。


Leave a comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です