camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine DESSAIGNE <>
Subject Re: BeanInfo performance issues
Date Tue, 05 Feb 2013 07:40:07 GMT

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:

Have a nice day,


2013/2/4 Antoine DESSAIGNE <>

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message