Question

我正致力于groovy代码性能优化。我使用jvisualvm连接到运行的应用程序并收集CPU样本。示例说 org.codehaus.groovy.reflection.CachedMethod.inkove 占用的CPU时间最多。我没有在样品中看到任何其他应用方法。

挖掘 CachedMethod.invoke 并了解哪些代码行确实会给性能带来惩罚的正确方法是什么？

感谢。

UPD ：我确实使用 Indy ，但它并没有帮助我。

我没有尝试引入 @CompileStatic ，因为我想在将groovy重写为java之前找到我的瓶颈。

我的问题与此主题类似：Call site caching faster than invokedynamic?

我有一个动态编写groovy脚本的代码。脚本模板看起来像这样：

def evaluateExpression(Map context){
    def user = context.user
    %s
}

其中％s 替换为

user.attr1 == '1' || user.attr2 == '2' || user.attr3 = '3'

从数据库中获取了一组（总共20个）替换。代码从DB中获取替换，创建GroovyScript并对其进行评估。我想瓶颈在于脚本执行。解决问题的正确方法是什么？

Answer 1

所以，我尝试了各种各样的事情

groovy-indy，不起作用
groovy-indy带有一些代码“优化”，不起作用。顺便说一句，我开始尝试使用try / catch，结果我的“热点”运行速度提高了4倍。我不擅长JVM内部，但互联网说 - try / catch阻止了优化。我认为这是一个基本事实。需要更深入地了解它的真正作用。
我放弃了，关闭了invokedynamic并用@CompileStatic重写了我的“最热门”代码。花了大约3-4个小时，我的代码现在运行速度提高了100倍。

以下是“invokedynamic support”的初始指标

count = 83043

     mean rate = 395.52 calls/second

 1-minute rate = 555.30 calls/second

 5-minute rate = 217.78 calls/second

15-minute rate = 82.92 calls/second

           min = 0.29 milliseconds

           max = 12.98 milliseconds

          mean = 1.59 milliseconds

        stddev = 1.08 milliseconds

        median = 1.39 milliseconds

          75% <= 2.46 milliseconds

          95% <= 3.14 milliseconds

          98% <= 3.44 milliseconds

          99% <= 3.76 milliseconds

        99.9% <= 12.19 milliseconds

以下是关闭ind的@CompileStatic指标。顺便说一下，如果打开“indy”，没有理由使用@CompileStatic。

 count = 139724

     mean rate = 8950.43 calls/second

 1-minute rate = 2011.54 calls/second

 5-minute rate = 426.96 calls/second

15-minute rate = 143.76 calls/second

           min = 0.02 milliseconds

           max = 24.18 milliseconds

          mean = 0.08 milliseconds

        stddev = 0.72 milliseconds

        median = 0.06 milliseconds

          75% <= 0.08 milliseconds

          95% <= 0.11 milliseconds

          98% <= 0.15 milliseconds

          99% <= 0.20 milliseconds

        99.9% <= 1.27 milliseconds

优化Groovy性能

1 个答案: