Hi

I have committed some improvements to trunk that all together speedup
unit testing.
So lets keep an eye on Hudson to see if its faster.

The last one before those changes was 272: And it took 3h2m to complete
https://hudson.apache.org/hudson/job/Camel.trunk.fulltest/272/




On Fri, May 6, 2011 at 3:31 PM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> Hi
>
> Seems like I am on the right path.
>
> I have implement so the core type converters is always "hardcode" loaded.
> And using lazy for unit testing camel-core by default.
>
> That cut time down to about 21-22m.
>
> But there is a big win at camel-spring as well.
> I have cut that down from 16m to 10m.
>
>
>
>
> On Fri, May 6, 2011 at 11:02 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
>> Hi
>>
>> I just did an experiment on camel-core to load the core type
>> converters faster (eg without classpath scanning).
>>
>> before: 26 min total testing time (default)
>> after: 24:30 min total testing time (lazy loading enabled)
>> special: 21:30 total testing time (lazy loading enabled, but forcing
>> it to never do classpath scanning)
>>
>> So we have a potential cut down from 1m30s to 4m30s. The latter is a
>> special where we force Camel to not even try classpath scanning. That
>> could be a viable approach to do for camel-core testing exclusively as
>> we know there are no other JARs on the classpath to scan.
>>
>>
>>
>>
>> Christian Schneider would not like this as the core type converters is
>> hardcoded, which means there would be package tangle ;)
>> As those hard coded type converters are in different packages.
>>
>>    public CorePackageScanClassResolver() {
>>        converters.add(DomConverter.class);
>>        converters.add(StaxConverter.class);
>>        converters.add(StreamSourceConverter.class);
>>        converters.add(XmlConverter.class);
>>        converters.add(CamelConverter.class);
>>        converters.add(CollectionConverter.class);
>>        converters.add(IOConverter.class);
>>        converters.add(NIOConverter.class);
>>        converters.add(ObjectConverter.class);
>>        converters.add(TimePatternConverter.class);
>>        converters.add(StreamCacheConverter.class);
>>        converters.add(BeanConverter.class);
>>        converters.add(GenericFileConverter.class);
>>        converters.add(FutureTypeConverter.class);
>>    }
>>
>>
>> Likewise we could make camel-spring be able to add to those core type
>> converters, so we do not have to classpath scanning there as well.
>> This should cut down testing time as well.
>>
>>
>> Any thoughts?
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cib...@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/
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cib...@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/
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cib...@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/

Reply via email to