camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller <christian.muel...@gmail.com>
Subject Re: BeanInfo performance issues
Date Wed, 06 Feb 2013 21:54:37 GMT
I went ahead and opened the issue [1] so we don't forget it.

[1] https://issues.apache.org/jira/browse/CAMEL-6043

Best,
Christian

On Tue, Feb 5, 2013 at 1:17 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message