camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Conceptual 'correctness' of using Camel Unit Tests
Date Sat, 07 May 2011 14:27:06 GMT

I managed to cut more time in camel-core and camel-spring.
Now I am down to 21m for camel-core and 7m for camel-spring, when
running on my laptop.

The trick is to lazy load the type converters. And if you use custom
type converters in unit tests, then put them into small packages so
Camel dont have to scan 100+ classes because you put them into a
package with many unit tests.

Another optimizations was to add some more basic converters String ->
Integer etc. that we used to have a JDK properties editor to converter
for us. But the JDK properties editor is a fallback converter, so what
happened normally, would be that camel would do a classpath scan for a
String -> Integer type converter, and if still none found, then
fallback and use that JDK properties editor.

Now by adding those very common used combinations of Integer <->
String etc. then that dont happen and we can rely on the type
converters from camel-core, which is now loaded "hardcoded".

I also checked if we could optimize loading Camel components, eg it
load those component scheme files from META-INF/services/. But there
is no speed gain there, as we use a FQN to load the resource from
classpath, and that is very fast also.

And another optimization was to reduce camel components from using
camel-core-test.jar and camel-spring-test.jar as they are very big,
and just add up and cause among others type convert scanning to be
slower. For example I cut 30s in camel-mina.

And I found some unit tests in camel-core which I could cut down time
with reducing delays, memory usages, and some sleep as well. That
gained about 1m.

Claus Ibsen
CamelOne 2011:
Twitter: davsclaus
Author of Camel in Action:

View raw message