Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of claus.ibsen@gmail.com
 designates 74.125.83.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=w9vmbCGsX9FMypAbuBQGv6/bXTMgUYdnViR9FXXnP3TPEzwo5aCIRRDT7Oxy05saU/
         H0mChZayuuQZDO5olIxvkYr/Qltcut2zhrFS6ajpvgSCS9orh9KrUpYkY6tLgcQXz9YK
         k7h+3yNrTgypxDQkdLgAkTQla9Y0fQ9vW1mv8=
MIME-Version: 1.0
In-Reply-To: <BANLkTi=9epCyNTo7mL59xLK4C_kp9KKLhA@mail.gmail.com>
References: <1304585813761-4372286.post@n5.nabble.com>
 <4DC26A3F.2060705@sopera.com>
 <BANLkTikjS=cdGPHaLZMTLoujJ4chOwiWFA@mail.gmail.com>
 <4DC2B8FC.2040109@sopera.com>
 <D62E12A3-B413-4D45-8042-9E4339A5F6C5@gmail.com>
 <BANLkTims1cyGkdYv75vDWSgy_rEc=cubRw@mail.gmail.com>
 <BANLkTinnzi7jNrNX140Uj03qCmkw23e9Bg@mail.gmail.com>
 <BANLkTi=Xmz8GZ_MksvEWjk5-M9fR2yvMOA@mail.gmail.com>
 <BANLkTi=9epCyNTo7mL59xLK4C_kp9KKLhA@mail.gmail.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Sat, 7 May 2011 16:27:06 +0200
Message-ID: <BANLkTin1mFBaQ=8XqOVpxweXavo18sjQyA@mail.gmail.com>
Subject: Re: Conceptual 'correctness' of using Camel Unit Tests
To: users@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hi

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.

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

2)
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".

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

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

5)
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
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/