Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Janne.Jalkanen@ecyrd.com
 designates 193.64.5.122 as permitted sender)
Message-Id: <E2346A64-4912-4FA7-BF7C-BBED0001538A@ecyrd.com>
From: Janne Jalkanen <Janne.Jalkanen@ecyrd.com>
To: jspwiki-dev@incubator.apache.org
In-Reply-To: <b90102160911281522y179f3f3sf4952884c044cd28@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Current tests slowdowns analysis
Date: Sun, 29 Nov 2009 02:09:14 +0200
References: <2D3C5451-391B-485F-8929-4C9277C6ED87@ecyrd.com>
 <b90102160911281452y4e8a9f7dg1ad623bbecc53d19@mail.gmail.com>
 <b90102160911281522y179f3f3sf4952884c044cd28@mail.gmail.com>


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
>>>
>>