Generally, the regular writing method is:
]
If you encounter big data If you change the length of the string, you will find that this is very resource intensive. It's not very efficient, and sometimes it's even unbearable.
If you need to introduce external Js, you need to refresh to execute
]
When explaining the reason I remembered that I saw it mentioned in master regular expression before. There is a difference between the engines of NFA and DFA. js/perl/php/java/.net are all NFA engines.
The difference in mechanism between DFA and NFA has five impacts:
1. DFA only needs to scan each character in the text string once, which is faster but has fewer features; NFA has to eat characters over and over again. Voicing characters is slow, but it has rich features, so it is widely used. Today's main regular expression engines, such as Perl, Ruby, Python's re module, Java and .NET's regex library, are all NFA.
2. Only NFA supports features such as lazy and backreference;
3. NFA is eager to claim credit, so the leftmost subregular expression is matched first, so it occasionally misses the best matching result; DFA It means "the longest left subregular expression is matched first".
4. NFA uses greedy quantifiers by default (that is, for patterns that are "repeated n" times such as /.*/ and /w /, it is carried out in a greedy manner and matches as many characters as possible until it can no longer give up) , NFA will match quantifiers first.
5. NFA may fall into the trap of recursive calls and perform extremely poorly.
backtracking
When NFA finds that it has eaten too much, it spits back one by one, looking for matches while spitting. This process is called backtracking. Due to the existence of this process, during the NFA matching process, especially when writing unreasonable regular expression matching, the text is scanned repeatedly, and the efficiency loss is considerable. Understanding this principle is very helpful for writing efficient regular expressions.
Locate/analyze the reason
When explaining the trim prototype method above. After testing, regardless of whether the results are correct, there are several methods that can resolve the number of echoes of the JS NFA engine
a. Remove the limiting quantifier, that is, change it to
Copy code
The code is as follows:
String.prototype.trim = function () {
return this.replace(/^[st] | [st ]$/g, '');
}
b. Remove end-of-string matching. That is, change it to:
Copy the code
The code is as follows:
String.prototype.trim = function ( ) {
return this.replace(/^[st ] /g, '');
}
c. Add multi-line matching. That is, change it to:
Copy the code
The code is as follows:
String.prototype.trim = function ( ) {
return this.replace(/^[st ] |[st ] $/mg, '');
}
从以上三种改法结合文中开头的NFA资料，我们可以大概的知道trim性能出现问题的原因
量词限定将优先匹配。
量词限定在结尾可能会使JS的正则引擎不停的回朔，出现递归的一个陷阱，这个递归的深度太深。如果字符串更大一点应该会出现栈溢出了。
多行既然能够匹配，而且性能消耗不大。性能上没有任何问题，从一个写这个正则程序的人角度上去看，多行明显比单行要替换的空串多得多。所以第二点的结论应该是对的
改良
首先确定匹配字符串的开始正则是没有任何效率问题的。而匹配结束的时候会出现性能问题，那可以采用正则与传统相结合来改善这个trim性能问题。
例如：
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
