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.ib...@gmail.com> wrote: > On Tue, Feb 5, 2013 at 8:40 AM, Antoine DESSAIGNE > <antoine.dessai...@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.dessai...@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: cib...@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > --
