codenarc-developer

[Codenarc-developer] Perf Boost - Lock Contention in Class.forName

[Hamlet D. <ham...@ca...>]

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...

Re: [Codenarc-developer] Perf Boost - Lock Contention in Class.forName

[Chris M. <chr...@ea...>]

First of all, thanks very much for all of your effort (and results!) on
improving performance.

Regarding this specific issue, I have not seen any replies yet from the
Groovy gurus. Unless they  come up with something unexpectedly helpful, I'd
be open to #1 (object pooling), but I think that would also require some
standard API and extra code to clear out ASTVisitor instances so that they
can be reused. And it would also  have to support concurrent access.

I'd probably lean toward #5 (leave it the way it is). I'm also wondering
whether this is one of those problems that might get better through eventual
performance improvements in the Groovy core.

Chris
-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Friday, September 16, 2011 2:47 AM
To: cod...@li...
Subject: [Codenarc-developer] Perf Boost - Lock Contention in Class.forName

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...


----------------------------------------------------------------------------
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer