Yep, I remember reading something about that, which is what
prodded me to take a look after I ran the tests and saw how
long they took....
several more questions:
1> Why call QueryUtils.check in the first place? I admit when I
looked that method over, my eyes glazed. I try to take things
in bite-sized chunks and that one stretched my jaw. Can anyone
give me a two-sentence statement of what is that method trying
to do and when it's desirable/necessary to call it? Because it looks
*very* expensive. If we just don't call it at all, we're down to < 1
sec.
I can imagine someone thinking "check, that sounds like a good thing
to call" without appreciating the expense. I wonder if this is the
*first* thing to check when looking at slow tests....
2> About reformatting. When I'm working, I'll often just check in a
reformatted file w/o any code changes to make comparisons
easier. I grabbed the codestyle.xml file from the SOLR site
but using that reformatted a bunch of stuff (in IntelliJ) that
confuse the code changes (to the TestCustomScoreQuery
file only). Just check it all in anyway? (really, submit a patch)?
Or do two separate patches? Or back out and not reformat
that file?
3> I'm assuming that all unit tests are also Java5, so I added
some generics notations. Is this acceptable?
Thanks
Erick
On Thu, Oct 29, 2009 at 3:12 PM, Mark Miller <markrmil...@gmail.com> wrote:
> +1 - I made a similar observation a while back and started an issue to
> address Junit test speeds:
>
> https://issues.apache.org/jira/browse/LUCENE-1844
>
> Erick Erickson wrote:
> > OK, I'm actually getting of my duff and trying to do something. And
> > I'm off today feeling ill, so I have a bit of time. So the rational
> > place to start is to get all the code and run the unit tests, and I've
> > even got them running in IntelliJ as well as the ant task. Will
> > wonders never cease.
> >
> > The unit tests in TestCustomScoreQuery take on the order of 80 seconds
> > on my machine. Before I go off the deep end I wanted to run what I've
> > found past y'all to see if it makes sense.
> >
> > Virtually all the time is taken up in the method logResult on the call
> > to QueryUtils.check(q, s). But the logResult method is called from
> > verifyResults method in a loop like:
> >
> > for (Iterator it = h1.keySet().iterator(); it.hasNext();) {
> > call logResult for 5 different queries.
> > }
> > But the queries don't change that I can see...
> >
> > Why couldn't we just call QueryUtils.check once for each of the 5
> > queries outside the for loop? Doing so reduces the time it takes for
> > the test from ~80 seconds to 9 seconds.
> >
> > If there're no objections, I'll make a patch. Which folks will
> > probably have to be patient with me since it'll be the first one I've
> > produced for this project.....
> >
> > While I'm at it, what are we thinking about using JUnit4? Looking
> > *briefly* at the code, this actually seems like it'd be difficult.
> > We'd have to deal with the LuceneTestCase superclass...
> >
> > Best
> > Erick
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>
