プロトタイプ関数をトリムして、js 正規表現_javascript スキルのパフォーマンスを確認します。

一般に、通常の記述方法は次のとおりです:

[Ctrl A すべて選択 注: 外部 Js を導入する必要がある場合は、更新して実行する必要があります

]

場合ビッグデータに遭遇します。文字列の長さを変更すると、リソースを非常に消費することがわかります。それはあまり効率的ではありませんし、場合によっては耐えられないことさえあります。

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title> </title> <meta http-equiv="Pragma" content="no-cache"> <meta http-equiv="Cache-Control" content="no-cache"> <meta http-equiv="Expires" content="0"> <meta http-equiv="ImageToolbar" content="no"> <style type="text/css" title="default" media="screen"> /*<![CDATA[*/ /*]]>*/ </style> <textarea> ここに十分なスペースまたはタブ文字を入力してください。
[Ctrl A すべて選択 注:

外部 Js を導入する必要がある場合は、更新して実行する必要があります
]

以前マスター正規表現で言及されていたのを思い出した理由を説明します。 NFA と DFA のエンジンには違いがあります。 js/perl/php/java/.net はすべて NFA エンジンです。
DFA と NFA のメカニズムの違いには、次の 5 つの影響があります。
1. DFA はテキスト文字列内の各文字を 1 回スキャンするだけで済みます。これは高速ですが、NFA は何度も文字を読み込む必要があります。 . 文字の音声化は遅いですが、機能が豊富なので、Perl、Ruby、Python の re モジュール、Java、.NET の正規表現ライブラリなど、今日の主要な正規表現エンジンはすべて NFA です。
2. NFA のみが遅延や後方参照などの機能をサポートします。
3. NFA はクレジットを要求するため、最も左の部分正規表現が最初に一致するため、最適な一致結果が得られないことがあります。最も長い左部分正規表現が最初に一致します。」
4. NFA はデフォルトで貪欲量指定子を使用します (つまり、/.*/ や /w / などの「n」回繰り返されるパターンの場合、貪欲な方法で実行され、できるだけ多くの文字と一致します)あきらめられなくなるまで)、NFA は最初に量指定子を照合します。
5. NFA は再帰呼び出しの罠に陥り、パフォーマンスが非常に低下する可能性があります。

バックトラッキング
NFA は食べ過ぎを検出すると、1 つずつ吐き戻し、吐きながら一致するものを探します。このプロセスはバックトラッキングと呼ばれます。この処理の存在により、NFAのマッチング処理中、特に無理な正規表現マッチングを記述する場合、テキストのスキャンが繰り返し行われることになり、効率の低下が大きくなります。この原則を理解することは、効率的な正規表現を作成するのに非常に役立ちます。

原因の特定/分析
上記のトリムプロトタイプの方法を説明するとき。テスト後、結果が正しいかどうかに関係なく、JS NFA エンジンのエコー数を解決できる方法がいくつかあります。

a. 制限量指定子を削除します。つまり、 コードをコピー

コードは次のとおりです。

String.prototype.trim = function () {
return this. replace(/^[st] | [st ]$/g, '');
}

b. 文字列の末尾の一致を削除します。つまり、次のように変更します:

コードをコピーします

コードは次のとおりです:

文字列.prototype.trim = function ( ) {
return this.replace(/^[st ] /g, '');

c. 複数行のマッチングを追加します。つまり、次のように変更します:

コードをコピーします コードは次のとおりです:

文字列.prototype.trim = function ( ) {
return this.replace(/^[st ] |[st ] $/mg, '');
从以上三种改法结合文中开头的NFA资料，我们可以大概的知道trim性能出现问题的原因
量词限定将优先匹配。
量词限定在结尾可能会使JS的正则引擎不停的回朔，出现递归的一个陷阱，这个递归的深度太深。如果字符串更大一点应该会出现栈溢出了。
多行既然能够匹配，而且性能消耗不大。性能上没有任何问题，从一个写这个正则程序的人角度上去看，多行明显比单行要替换的空串多得多。所以第二点的结论应该是对的
改良
首先确定匹配字符串的开始正则是没有任何效率问题的。而匹配结束的时候会出现性能问题，那可以采用正则与传统相结合来改善这个trim性能问题。
例如：

<script type="text/javascript">//<![CDATA[ String.prototype.trim = function () { var s = this.replace(/^[\s\t ]+/g, ''); 从s后端开始查找，并回循环到最后一个非空字符串，代码略。 } //]]></script>
[Ctrl+A 全选 注:如需引入外部Js需刷新才能执行]