如何解决RegEx的Kotlin性能问题
我正在制作一个使用正则表达式的日志解析应用程序，并且看到一些奇怪的行为，希望有人可以帮助解释并提出克服的技巧。首先，这是代码：
import java.io.File
var regex1Count = 0
var regex2Count = 0
var noMatchCount = 0
val regex1 = Regex(".*error.*",RegexOption.IGNORE_CASE)
val regex2 = Regex("exception|crashed|death|fatal|killed| f | e ",RegexOption.IGNORE_CASE)
fun main(args: Array<String>) {
val file = File("C:\\Users\\pnogas\\Desktop\\mobicontrol.log")
val time = System.currentTimeMillis()
val result = file.useLines { sequence ->
sequence.mapNotNull { line ->
parseLine(line)
}.toList()
}
println("took ${(System.currentTimeMillis() - time) / 1000.0} seconds")
println("regex1Count = $regex1Count,regex2Count = $regex2Count,noMatchCount = $noMatchCount")
}
private fun parseLine(line: String) {
for (filter in listOf(regex2,regex1)) {
if (filter.containsMatchIn(line)) {
if (regex1 == filter) {
regex1Count++
} else if (regex2 == filter) {
regex2Count++
}
return
}
}
noMatchCount++
}
当我运行这段代码时，它输出：
took 4.198 seconds
regex1Count = 16,regex2Count = 101,noMatchCount = 11559
但是，如果我将一行更改为listOf（regex1，regex2）而不是listOf（regex2，regex1）：
took 35.049 seconds
regex1Count = 18,regex2Count = 99,noMatchCount = 11559
我知道通配符正则表达式的运行成本将更高，但是数字表明更改顺序只会使其运行两倍，与处理的总行数相比，这似乎可以忽略不计。如果使列表仅包含regex1，我将获得相同的性能。
最重要的是，当我使用notepad ++在同一文件上执行相同的正则表达式搜索时，我得到了18个结果，但结果几乎是立即产生的。我知道JVM不能像本机编译代码那样执行出色，但是真的可以预期它运行得慢得多。还是我完全以错误的方式来解决这个问题？
由于到目前为止的答复，有一些澄清
-
我同意使用“错误”代替“。*错误。*”将解决此处的时间问题。对我来说，问题是用于生成RegEx的字符串将来自应用程序中的用户输入。我想我可以在我的应用中做的一件事是进行一些预处理：（例如，删除任何前导或尾随通配符，并保留内部通配符）
-
我知道，由于第一个匹配的正则表达式返回，因此顺序很重要。再次，因为这将来自用户输入，所以我可以选择让他们负责选择绩效订单。
-
欢迎使用其他提高性能的技巧，但是我想在这里回答的主要问题是为什么订单使SUCH在我的示例中与众不同？除非我想念什么...
在第一个示例中： regex2运行11676次（匹配101次） regex1运行11575次（未运行regex2匹配的101次）
在第二个示例中，： regex1运行11676次（匹配18次） regex2运行11658次（未运行匹配的regex1 18次）
因此regex1的运行时间增加了0.86％，regex2的运行时间减少了0.15％，但是运行时间增加了754％？ 我唯一的随机猜测是，有一种JIT JVM Warmup首先运行简单的正则表达式，从而使第二个更复杂的正则表达式运行得更快，我应该插入一个虚拟RegEx，在执行我关心的正则表达式之前，它总是会很快运行，以提高性能。 .. ???
解决方法
这是一个很复杂的问题，所以很长的回答（很遗憾是不完整的），请提前对不起。
您的测试代码有误解。列表中的第一个正则表达式将在 all 行中进行评估，因此在您的示例中为11676次。您的regex1Count变量 only 返回（昂贵）搜索操作返回正匹配项的次数。因此，更改正则表达式的评估顺序可能会对性能产生很大的影响，因为第一个正则表达式将用作主要过滤器。
此外，正如@PiRocks所述，可以简化正则表达式。更重要的是，由于它的简单性（搜索单个单词），这里甚至不需要使用正则表达式。您可以执行文字搜索，这会快得多。
此外，作为JVM用户已有数年之久，我还必须解决关于性能的一个常见误解：JVM应用程序并不总是比本地应用程序慢。每种技术都在各自的领域发挥作用，要获得最佳性能，通常是为正确的任务选择正确的工具。例如，JVM使用JIT对经常使用的代码执行积极的优化，而垃圾回收器则大大降低了变量分配的成本。
无论如何，在当前情况下，无论两端使用何种技术，我们都无法将手工代码的性能与交付的应用程序进行比较。为什么呢因为我们不能确定比较等效的工作流程。在这里，也许记事本具有：
- 将整个文件缓冲在内存中，
- 事先创建了一个索引，
- 分析了输入搜索正则表达式，并删除了执行前不必要的复杂性，
- 对搜索进行多线程处理，
- 等
我试图通过Kotlin游乐场重现您的案件：
- 生成随机文本行
- 测试您的
regex1 - 通过Java模式api比较相同的正则表达式
- 测试
regex2 - 对“错误”一词进行文字搜索。
结果显而易见：与.*error.*正则表达式相比，文字搜索快如闪电。正则表达式是一个非常强大的工具，但是它们的复杂性可能难以管理。
现在，仍然有一个问题：JVM正则表达式在性能方面执行不佳吗？要回答这个问题并不简单。天真地，我们可以尝试使用我制作的游乐场（请参见下面的代码），用另一种语言重写它，并比较两者的输出。但是由于JVM JIT /预热时间，比较会有所偏差。
我们必须广泛遍历这两种实现方式，收集统计信息并最终比较结果以获得深刻的见识。
供参考，以下是游乐场及其输出：
Log example :
ex quam Suspendisse vel sed rhoncus aliquet. elit.
nibh amet,sed nibh eleifend diam amet ex eleifend.
Measure Regex on 12000 lines
Regex 1 for 10 words per line took 0.439 seconds
Regex 1 for 20 words per line took 0.843 seconds
Java pattern 1 for 10 words per line took 0.407 seconds
Java pattern 1 for 20 words per line took 1.347 seconds
Regex 2 for 50 words per line took 0.463 seconds
Literal search for 1000 words per line took 0.836 seconds
import kotlin.random.Random
import java.lang.StringBuilder
import java.lang.System
import java.util.regex.Pattern
fun main() {
println("Log example :")
generateLogs(nbLines = 2,wordPerLine = 10).forEach { println(it) }
println("\nMeasure Regex on 12000 lines\n")
val regex1 = Regex(".*error.*",RegexOption.IGNORE_CASE)
for (nbWords in listOf(10,20)) {
roughMeasurement("Regex 1 for $nbWords words per line") {
val matched = generateLogs(wordPerLine = nbWords)
.count { regex1.containsMatchIn(it) }
}
}
val javaPattern = Pattern.compile(".*error.*",Pattern.CASE_INSENSITIVE)
for (nbWords in listOf(10,20)) {
roughMeasurement("Java pattern 1 for $nbWords words per line") {
val matched = generateLogs(wordPerLine = nbWords)
.count { javaPattern.matcher(it).find() }
}
}
val regex2 = Regex("(exception)|(crashed)|(death)|(fatal)|(killed)| f | e ",RegexOption.IGNORE_CASE)
roughMeasurement("Regex 2 for 50 words per line") {
val matched = generateLogs()
.count { regex2.containsMatchIn(it) }
}
roughMeasurement("Literal search for 1000 words per line") {
val matched = generateLogs(wordPerLine = 1000)
.count { it.indexOf("error") >= 0 }
}
}
fun roughMeasurement(title: String,action: () -> Unit) {
val start = System.nanoTime()
action()
val end = System.nanoTime()
val timeSeconds = (end - start).toDouble() * 1e-9
println("$title took ${"%.3f".format(timeSeconds)} seconds")
}
/*
* LOG GENERATION UTILITIES
*/
fun generateLogs(nbLines : Int = 12000,wordPerLine : Int = 50) : Sequence<String> {
return (1..nbLines).asSequence()
.map { generateSentence(wordPerLine) }
}
fun generateSentence(nbWords : Int) : String {
require(nbWords > 2) { "Need more than two words per sentence" }
val builder = StringBuilder(nbWords * 3)
for (i in 0..nbWords-2) {
builder.append(wordPool.pick()).append(' ')
}
builder.append(wordPool.pick())
return builder.toString()
}
fun List<String>.pick() = this[Random.nextInt(0,size)]
/**
* Authorized words in log generation.
* To test for worst-case scenario,we've omitted searched keywords:
* error exception crashed death fatal killed
*/
val wordPool = """
Lorem ipsum dolor sit amet,consectetur adipiscing elit.
Suspendisse eu ex eu ligula egestas posuere ac et velit.
Fusce sed nisl diam. Proin eleifend nibh vel felis fermentum,a luctus diam eleifend. Pellentesque feugiat magna sit amet
arcu eleifend,vel lacinia justo aliquet. In quam magna,rhoncus a lacinia vel.
""".split(Regex("\\s+"))
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。