嵌入式java基准测试
在尝试使Java在计算机语言基准游戏的regexdna挑战中排名第一时，我正在研究Java正则表达式库的性能。 我可以找到的最新网站是2010年的tusker.org 。因此，我决定使用Java Microbenchmarking Harness重做测试并发布结果（破坏性警告：某些非传统的解决方案使Java排名第一）。
TL; DR ：正则表达式非常适合临时查询，但如果您对性能敏感，则应手动编写解决方案代码（这并不意味着您必须从绝对零开始–例如，Google Guava库包含一些不错的实用程序 ，可以帮助编写可读性强的代码。
现在，对于一些总结性能的图表–该测试是在带有OpenJDK 1.8.0_66的64位Ubuntu 15.10计算机上运行的：
观察结果
- 正则表达式没有“标准”，因此当给定特定的正则表达式和特定的字符串以进行匹配时，不同的库可能会表现出不同的行为，即。 一个可能会说它匹配，但另一个可能会说它不匹配。 例如，即使我使用了一组非常少的测试用例（针对6个字符串检查了5个正则表达式），但是只有两个库设法匹配/不正确地匹配了它们（其中一个是java.util.Pattern）。
- 要使您的正则表达式正确，可能需要不止一次的尝试（例如regexpal或Regex Coach之类的工具对于实验非常有用）
- 正则表达式的性能很难预测（有时它可能会基于输入长度而呈指数复杂性 ）–因此，如果您接受Internet上任意用户的正则表达式（例如搜索引擎，例如将允许使用正则表达式进行搜索）
- 似乎没有一个库正在积极开发中（事实上tusker.org原始列表中的许多库现在不可用），而且其中许多库都比内置的juPattern慢 ，因此， 如果使用正则表达式应可能是首选。
- 这么说，硬件以及两者的性能JVM已经相当大，因此，如果您正在使用这些库之一，它通常是运行一个数量级的速度比它是在五年前。 因此，无需快速替换工作代码（除非您的分析器说这是一个问题:-)）
- 当心循环中对String.split的调用。 尽管它针对特定情况（例如一字符正则表达式）进行了一些优化，但您几乎应该始终：
- 看看是否可以使用Google Guava的Splitter之类的工具
- 这两个惊喜是dk.brics.automaton ，它比其他所有东西都好几个数量级，但是：
- 最新版本是2011年，似乎是一个学术项目
- 另一个惊喜是kmy.regex.util.Regex ，尽管自2000年以来未进行更新，但它的性能优于java.util.Pattern，并且通过了所有测试（当然，其中没有很多测试）。
使用的库的完整列表：
| 库名称和版本（发布年份） | 在Maven Central中可用 | 执照 | 平均操作/秒 | 平均操作/秒（大文本） | 通过测试 |
|---|---|---|---|---|---|
| j.util.Pattern 1.8（2015） | 否（JRE附带） | JRE许可证 | 19689 | 22144 | 5之5 |
| dk.brics.automaton.Automaton 1.11-8（2011） | 是 | BSD | 2 600 225 | 115374276 | 5分之2 |
| org.apache.regexp 1.4（2005） | 是 | 阿帕奇（？） | 6738 | 16895 | 5之4 |
| com.stevesoft.pat.Regex 1.5.3（2009） | 是 | LGPL v3 | 4191 | 859 | 5之4 |
| net.sourceforge.jregex 1.2_01（2002） | 是 | BSD | 57811 | 3573 | 5之4 |
| kmy.regex.util.Regex 0.1.2（2000） | 没有 | 艺术许可 | 217803 | 38184 | 5之5 |
| org.apache.oro.text.regex.Perl5Matcher 2.0.8（2003） | 是 | 阿帕奇2.0 | 31906 | 2383 | 5之4 |
| gnu.regexp.RE 1.1.4（2005？） | 是 | GPL（？） | 11848 | 1509 | 5之4 |
| com.basistech.tclre.RePattern 0.13.6（2015） | 是 | 阿帕奇2.0 | 11598 | 43 | 5之3 |
| com.karneim.util.collection.regex.Pattern 1.1.1（2005？） | 是 | ？ | – | – | 5分之2 |
| org.apache.xerces.impl.xpath.regex.RegularExpression 2.11.0（2014） | 是 | 阿帕奇2.0 | – | – | 5之4 |
| com.ibm.regex.RegularExpression 1.0.2（不再可用） | 没有 | ？ | – | – | – |
| RegularExpression.RE 1.1（不再可用） | 没有 | ？ | – | – | – |
| gnu.rex.Rex吗？ （不再可用） | 没有 | ？ | – | – | – |
| monq.jfa.Regexp 1.1.1（不再可用） | 没有 | ？ | – | – | – |
| com.ibm.icu.text.UnicodeSet（ICU4J） 56.1（2015） | 是 | ICU许可证 | – | – | – |
如果要重新运行测试，请签出源代码并按以下方式运行它：
# we need to skip tests since almost all libraries fail a test or an other
mvn -Dmaven.test.skip=true clean package
# run the benchmarks
java -cp lib/jint.jar:target/benchmarks.jar net.greypanther.javaadvent.regex.RegexBenchmarks最后， 计算机语言基准游戏的regexdna挑战如何？ 我通过使用位操作来检查8字节的块（如果它们可能匹配），从而使Java达到了＃1的水平，然后仅对正则表达式进行测试。 就像我之前说的：如果要提高性能，则需要编写自定义解析器。
翻译自: https://www.javacodegeeks.com/2015/12/java-regular-expression-library-benchmarks-2015.html
嵌入式java基准测试
