John Stecher commented on OPENJPA-160:

>From the testing that we have done fooling with different prototyped versions 
>and making different fields in BrokerImpl static to avoid recreation I am 
>pretty (almost 100%) sure the cost we are looking at here is just that of 
>creating this class in general being expensive.  I would love to have someone 
>else profile the code with different tools than I have at my disposal and see 
>if they find a different culprit.

WRT pooling I think a reasonable solution would not be to create a massive pool 
of objects but just one per thread-id to optimize for the general case.  I am 
assuming that one Broker per thread is common.  I am with everyone else in that 
I would love to keep configuration to a minimum overall.  I am not a big fan of 
exposing pool settings to a user as if we decide to change it later on you 
might have to support the setting beyond when you really want too. :-)  Any 
thoughts on why this would not work or can someone enlighten me on what the 
general use case is?

Patrick - I would be worried about the Clone being almost as heavy weight as 
what we are doing now but need to implement and test it.  

> Reuse BrokerImpl objects
> ------------------------
>                 Key: OPENJPA-160
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-160
>             Project: OpenJPA
>          Issue Type: Sub-task
>            Reporter: Michael Dick
>         Attachments: perf2.jpg, perf3.jpg

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to