正则表达式是一项代价高昂的操作？似乎至少

我正在为字符串编写正则表达式模式.字符串是常量类型/结构.我的意思是,它看起来像(这种格式不是那么重要,请看下一个例子) -

[Data Code Format]: POP N/N/N (N: object): JSON object data

这里N代表数字或数字.而[]里面的是一组字符串块.但是,这种格式是不变的.

所以,我写了一个正则表达式 -

\s*((?:\S+\s+){1}\S+)\s*(?:\((?:.*?)\))?:\s*(\S*)\s*(\w+)

记住这个字符串的例子 -

%DATA-4-JSON: POP 0/1/0 (1: object): JSON object data

它工作得很好,但是,我在regex101.com上看到的是有一个成功的匹配.但是,它已经经历了330步骤来实现这一目标.

Screenshot-

我的问题是,它采取了330步骤来实现这一目标(至少在我的脑海里,我觉得它非常沉重),我想这可以通过使用if-else和其他较小步骤的比较来实现吗？

我的意思是,正则表达式字符串解析如此沉重？对于我需要解析的10000个字符串的330步将会很重吗？

当您使用正则表达式时,如果您使用回溯,它们可能会很昂贵.当你使用量词与随之而来的模式,可以彼此匹配(并且如果它们之间的模式可以匹配空字符串(通常,声明的*,{0,x}或?量词)),回溯可能发挥不好招你.

你的正则表达式有什么不好的？

轻微的性能问题是由不必要的非捕获组引起的(?:\S+\s+){1}.它可以写成\S+\s+,它已经减少了步数(一点,302步).但是,最糟糕的部分是\S匹配:分隔符.因此,正则表达式引擎必须尝试许多可能的路由来匹配预期匹配的开始.将其替换\S+\s+\S为[^:\s]+\s+[^:\s]+,步数将减少到159!

现在,来(?:\((?:.*?)\))?- 删除不必要的内部非捕获组会给出另一个轻微的改进(148步),并且替换.*?为否定的字符类会带来另一个提升(139步).

我现在用它:

\s*([^:\s]+\s+[^:\s]+)\s*(?:\([^()]*\))?:\s*(\S*)\s*(\w+)

如果首字母\s*是强制性的,那将是另一种增强,但你会有不同的匹配.