camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: BeanInfo performance issues
Date Tue, 05 Feb 2013 12:17:21 GMT
On Tue, Feb 5, 2013 at 8:40 AM, Antoine DESSAIGNE
<antoine.dessaigne@gmail.com> wrote:
> Hi,
>
> I opened nabble and the archive in order to see if my message went through.
> It was the case but the attachment was removed. So you can find the patch
> right here: http://pastebin.com/WXtqUPGp
>
> Have a nice day,
>

Hi Antonie

Thanks for sharing this.
I suggest to log a JIRA ticket with an improvement and attach your
code to the JIRA.
This is how ASF can accept contributions.


That said, caching is always comes with a price.
In a dynamic environment classes can come and go, and thus you would
need to keep your caches with weak references,
or a way to unload class types, so classloaders dont get stuck.

But having the JIRA allows us to take a look at this and find a better
caching solution.
We do have a LRUSoftCache in Camel that may be a better fit.




> Antoine.
>
>
> 2013/2/4 Antoine DESSAIGNE <antoine.dessaigne@gmail.com>
>
>> Hi everyone,
>>
>> We use Camel 2.10.3 in order to integrate our software with other products.
>>
>> We noticed performance issues with Simple expressions like ${body[name]}
>> so we tried to analyse the root cause. It looks like a lot of BeanInfo
>> instances are created but for the same class type. Since each creation
>> introspects the underlying type, we end up introspecting the same class
>> over and over.
>>
>> In order to see if our assessment was right we created some BeanInfo cache
>> in the Registry (because we didn't know where to put it).
>>
>> In order to get some benchmarks we tried the following thing: execute a
>> loop that performs an evaluation 10000 times. We took the average of 5
>> executions without the first one. Here are the results:
>> ${body} without the cache: 359ms
>> ${body[name]} without the cache: 12220ms
>> ${body[name]} with the cache: 620ms
>>
>> You'll find attached the patch of camel-core with our cache and test class.
>>
>> It's far from being ready to integrate on the trunk because there is so
>> much we don't know:
>> * What are the concurrency issues with BeanInfo ?
>> * Is it a good idea to cache the BeanInfo instances ?
>> * If the cache is a good idea, what's the best place to put it ? what's
>> the right caching level (inside BeanInfo or outside) ?
>>
>> Thanks a lot for your replies on this subject,
>>
>> Have a nice day,
>>
>> Antoine.
>>
>>



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Mime
View raw message