Perl のインタプリタは C で書かれていますが、perl は C に比べて文字列の照合が高速です。間違っている場合は修正してもらえますか。そして、もしそれが事実なら、これは説明できますか?
2 に答える
Perlは確かにCで書かれています(そしてPerlでは、私は推測します)。
Cには文字列照合機能がないため、Perlよりも遅く(または速く)なることはありません。もちろん、Cで文字列照合ライブラリを作成し、Perlで文字列照合と比較することはできますが、Cには文字列照合がないため、Cを比較することはできません。
demerphq(Perlの正規表現エンジンの達人の1人)は最近、「他の言語でのP5 REと他のREの速度(定義はしません)はどれくらいですか?」と返信しました。次のように:
これは難しい質問です。私の一般的な経験では、一部の正規表現エンジンは一部のパターンに対してより速く一致しますが、多くの正規表現エンジンはより遅く、多くの場合はるかに遅く一致しません。実際には、perlsエンジンは他の多くのエンジンよりも競争力があるか優れています。したがって、これに関するベンチマークには本当に注意する必要があります。多くの場合、Perlの方が遅い成功事例のみを調べます。これは意図的な設計上の決定であり、多くのシナリオでは、パターンが一致するよりも頻繁に一致しないため、通常は迅速に失敗するようにしています。
この種の比較を難しくするもう1つの問題は、Perlの正規表現エンジンには非常に豊富な機能セットがあり、他のエンジンは機能とパフォーマンスを交換することが多いということです。Perlの正規表現エンジンは非常に優れたUnicodeサポートを備えており、他のエンジンではサポートされていないことがよくあります(多くの場合、これは彼らの主張にも関わらずです)。
この種のものの例は、Perlが使用する「必須のサブストリング」ロジックです。エンジンは、パターンが一致するために存在しなければならないパターン内の最長の文字列を見つけます。次に、Fast-Boyer-Moore(FBM)マッチングを使用して、文字列が存在するかどうかを判断します。そうでない場合は、正規表現エンジンを起動しません。これは、理論的にはPerlが真のDFAよりも大幅に速くパターンを拒否できることを意味し、実際にはそうすることがよくあります。DFAは通常、長さNの文字列に対してN回の操作を実行する必要があります。FBMはベストケースのN / L検査を実行できます。ここで、Nは文字数、Lは必須文字列の長さです。
Perlの文字列照合コードは、Cの(少数の)文字列処理ライブラリ関数を使用する必要はありません。したがって、Cライブラリ実装者のアルゴリズムの選択によって制限されることはなく、独自の決定を行うことができます。
私の答えは、PerlがCで実装されているという理由だけで、Perlの文字列照合が特定のC実装よりも高速であってはならない理由はないと思います。実際に高速かどうかはわかりません。