[Codenarc-developer] Perf Boost - Lock Contention in Class.forName
Brought to you by:
chrismair
From: Hamlet D. <ham...@ca...> - 2011-09-16 06:47:33
|
Hi Chris, If you look at CodeNarc in a perf analyzer, then you'll see a few cases of threads blocking calling the synchronized Class.forName method. On average, I see about 9 seconds of blocking across three threads for every ~37 second run. If we could remove this synchronization then we could get /maybe/ another 8-10% improvement. The problem is in the AST Visitor Rules that have a Class field like this: Class astVisitorClass = SomeClass The parent rule reads this field and instantiates the visitor once for every source file. But the slowness does not come from the reflection of Class.newInstance. I changed the rules to all create a instance directly like this, and saw no improvement: @Override AstVisitor getAstVisitor() { new SomeClass() } The problem is that Groovy uses Class.forName even when you directly invoke a constructor call like this. There seems is no way to avoid the reflection in Groovy. I'll check the mailing list to see if there is any easy solution, but here is what I see as possible solutions: 1 Use object pooling - Don't create new rule instances, cache them instead 2 Rewrite every rule in Java 3 Write an ASTtransformation annotation that converts these statements to the correct bytecode 4 Use ASM (or something) to change the bytecode at compile time 5 Leave it as is I don't know any other good ways to do it. Option 1 is not so bad, Option 2 is unappealing, Option 3 is fragile. Thoughts? -- Hamlet D'Arcy ham...@ca... |