incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: Current tests slowdowns analysis
Date Sun, 29 Nov 2009 00:09:14 GMT

I've been thinking about moving to JUnit4, but so far there hasn't  
really been a compelling reason. This could be it...

One possible way could of course to be to override the Stripes default  
implementation for tests.  That would make it fairly fast.

/Janne

On Nov 29, 2009, at 01:22 , Andrew Jaquith wrote:

> Looks like if we used JUnit 4, we could use methods annotated with
> @BeforeClass to set up fixtures that would persist between tests in a
> single test class. We'd get a lot of savings in classes like
> JSPWikiMarkupParserTest that have 200 tests, for example.
>
> Also, I've investigated (a little) methods for reducing the need to
> run ResolverUtil. We would probably still need to run it at least
> twice: once for all of JSPWiki's needs, and once for Stripes itself.
> But we'd need some way of registering "interest" in particular classes
> to discover, so that it could all be done in one pass. I wrote the
> class org.apache.wiki.ui.stripes.IsOneOf exactly for this purpose
> (match against multiple target classes), but it's not optimized for
> speed yet.
>
> Andrew
>
> On Sat, Nov 28, 2009 at 5:52 PM, Andrew Jaquith
> <andrew.r.jaquith@gmail.com> wrote:
>> Janne, I think your attachment got stripped out. Can you re-send
>> (maybe directly?)
>>
>> I agree that we ought to figure out some way of using some sort of
>> singleton (or singleton-per-wikiengine) object to stash the results  
>> of
>> findImplementations(). Not sure how this would work with JUnit,  
>> though
>> -- I should do some research. What we'd need is the ability to create
>> test fixture objects that persist across the entire run...
>>
>> Andrew
>>
>> On Sat, Nov 28, 2009 at 4:48 PM, Janne Jalkanen
>> <Janne.Jalkanen@ecyrd.com> wrote:
>>> Folks, here's a screenshot from JProfiler.  This should explain  
>>> why our
>>> tests are fairly slow...
>>>
>>>
>>>
>>>
>>>
>>> Simply put; we're not using EhCache, and also we're calling Stripes
>>> ResolverUtil.findImplementations twice per WikiEngine startup.  So  
>>> it might
>>> make sense to move findImplementations() calls into a singleton or
>>> something.  But I'm not too sure whether it makes sense  
>>> considering restarts
>>> - or perhaps restarts should clean away the singleton cache?
>>>
>>> (This is after about 700 tests were run; I didn't want to wait  
>>> until they
>>> had all finished, since it had already taken about two hours with  
>>> profiling
>>> on...)
>>>
>>> Priha can be seen taking quite a lot of time as well, but that's  
>>> because it
>>> needs to hit the disk all the time.  More optimization for  
>>> FileProvider is
>>> needed, but partly it's also because we're not caching anything.
>>>
>>> /Janne
>>>
>>


Mime
View raw message