こんばんは、ハラジテリ！ 今日は、ORegex .NETのパフォーマンス評価について少しお話したいと思います。
ここで私の以前の記事を読んだ場合、私の意見では、速度の比較評価なしで何かを想像することはあまり説得力がありませんでした、そう思いませんか？ はいの場合は、猫の下であなたに。
私は長い間自分自身を苦しめないために、ベンチマークに何を含めるべきかについて長い間考えていました。 これに多くの時間/労力を費やしたくはありませんでした。SF作家と私はまったく役に立たないので、最も単純な比較を行うことにしました-テキスト内の部分文字列を見つけます。 私の意見では、パフォーマンステストでは、シンボルもオブジェクトであるため、これが最善のソリューションです。 すべてのコードがgitハブのテストプロジェクトに存在することに注意してください。何もする必要がない場合は実行できます=）
MicrosoftのORegexおよびRegexエンジンがあります。必要なのは、両側の同様のパターン、ORegexの各文字のラムダを記述することだけです。テストケースを作成することを忘れないでください。 長く考える必要はありませんでしたが、ツールが3つのタスクにどのように対応するかを確認することにしました。
- 現実 （htmlタグの解析、高度に構造化されたデータの実用的なチェック）
- ランダム （完全にランダムなデータセット内のオカレンスの検索と同様）
- エラー （バックトラッキングをキャンセルした人はいないため、非常に不正なデータがあるセットを確認する必要があります）
現実
ニュースサイトからページが選択され、タスクは20回の繰り返しですべてのpタグを見つけるように設定されました。 ご想像のとおり-正規表現が先です。 最初の反復での両方のツールは、コールドスタートとほぼ同じ結果を示しました。 最初の反復の後、速度の差は約10倍異なりました。
ORegexパターン：{b1o} {p} {b1c}。*？{B1o} {s}} {p} {b1c}; 正規表現パターン： <p
>。*？ </p
>
| いや | オレゲックス | 正規表現 | 比率 |
|---|---|---|---|
| 1 | 00：00：00.0040204 | 00：00：00.0058571 | 1.46 |
| 2 | 00：00：00.0030944 | 00：00：00.0003172 | 0.1 |
| 3 | 00：00：00.0032093 | 00：00：00.0003195 | 0.1 |
| 4 | 00：00：00.0031040 | 00：00：00.0003172 | 0.1 |
| 5 | 00：00：00.0032354 | 00：00：00.0003149 | 0.1 |
| 6 | 00：00：00.0031703 | 00：00：00.0003153 | 0.1 |
| 7 | 00：00：00.0031220 | 00：00：00.0003187 | 0.1 |
| 8 | 00：00：00.0030883 | 00：00：00.0003187 | 0.1 |
| 9 | 00：00：00.0036790 | 00：00：00.0003674 | 0.1 |
| 10 | 00：00：00.0030902 | 00：00：00.0003145 | 0.1 |
| 11 | 00：00：00.0030787 | 00：00：00.0003130 | 0.1 |
| 12 | 00：00：00.0030752 | 00：00：00.0003149 | 0.1 |
| 13 | 00：00：00.0030975 | 00：00：00.0003183 | 0.1 |
| 14 | 00：00：00.0032250 | 00：00：00.0003777 | 0.12 |
| 15 | 00：00：00.0031166 | 00：00：00.0003179 | 0.1 |
| 16 | 00：00：00.0030852 | 00：00：00.0003141 | 0.1 |
| 17 | 00：00：00.0031178 | 00：00：00.0003160 | 0.1 |
| 18 | 00：00：00.0030913 | 00：00：00.0003160 | 0.1 |
| 19 | 00：00：00.0030787 | 00：00：00.0003133 | 0.1 |
| 20 | 00：00：00.0030818 | 00：00：00.0003118 | 0.1 |
ランダム
次に、データがロジックにまったく役立たない場合の違いを確認する価値があります。 テストのために、指定された文字の完全にランダムなセットでファイルが作成されました。
ORegexパターン：{a}（{b} {a}）+; 正規表現パターン：a（ba）+
| いや | オレゲックス | 正規表現 | 比率 |
|---|---|---|---|
| 1 | 00：00：00.1785877 | 00：00：00.0622146 | 0.35 |
| 2 | 00：00：00.2141055 | 00：00：00.0578735 | 0.27 |
| 3 | 00：00：00.2148457 | 00：00：00.0539055 | 0.25 |
| 4 | 00：00：00.1984781 | 00：00：00.0499280 | 0.25 |
| 5 | 00：00：00.2073454 | 00：00：00.0634693 | 0.31 |
| 6 | 00：00：00.1592644 | 00：00：00.0842834 | 0.53 |
| 7 | 00：00：00.2167805 | 00：00：00.0527719 | 0.24 |
| 8 | 00：00：00.2012316 | 00：00：00.0511291 | 0.25 |
| 9 | 00：00：00.1928555 | 00：00：00.0504931 | 0.26 |
| 10 | 00：00：00.1887427 | 00：00：00.0546691 | 0.29 |
| 11 | 00：00：00.1663168 | 00：00：00.0741461 | 0.45 |
| 12 | 00：00：00.1628335 | 00：00：00.0742250 | 0.46 |
| 13 | 00：00：00.2077626 | 00：00：00.0481913 | 0.23 |
| 14 | 00：00：00.1709487 | 00：00：00.0501648 | 0.29 |
| 15 | 00：00：00.1869102 | 00：00：00.0477373 | 0.26 |
| 16 | 00：00：00.2173555 | 00：00：00.0629728 | 0.29 |
| 17 | 00：00：00.1897196 | 00：00：00.0495571 | 0.26 |
| 18 | 00：00：00.1939370 | 00：00：00.0494173 | 0.25 |
| 19 | 00：00：00.2249846 | 00：00：00.0479044 | 0.21 |
| 20 | 00：00：00.2037242 | 00：00：00.0815932 | 0.4 |
この場合、RegexからのORegexの遅れはわずか約3倍です。
エラー
さて、現時点では、ORegexが高度に構造化されたデータとランダムセットの文字シーケンスを見つけることで負けていることは明らかですが、エラーのあるケースはどうでしょうか。 2つのツールがbactracking-proofである限り、テストは簡単です。 このために、特別なテンプレートが設定され、「x」の1つからの文字列サイズが150文字ずつ徐々に増加しました。その結果、3回目の反復で、Regexはほぼ30倍遅れました。
ORegexパターン：{x} + {x} + {y} +; 正規表現パターン：x + x + y +
| いや | オレゲックス | 正規表現 | 比率 |
|---|---|---|---|
| 1 | 00：00：00.0082144 | 00：00：00.0094231 | 1.15 |
| 2 | 00：00：00.0005045 | 00：00：00.0064406 | 12.76 |
| 3 | 00：00：00.0114383 | 00：00：00.3322330 | 29.05 |
まとめ
要約すると、もちろん、このツールを使用して部分文字列を検索するのは不合理で愚かなことです。 これには、より高速な正規表現エンジンがあります。 一連のオブジェクト（遺伝子のシーケンス内のゲノム、単語内の単純なエンティティ、メモリダンプ内のオブジェクトなど）のパターンを見つけるためのタスクが迅速、簡単、かつ理解できる場合、そのような速度の違いは私の意見ではかなり受け入れられます。
以上です。 ご清聴ありがとうございました！ =）