lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <erickerick...@gmail.com>
Subject Re: (LUCENE-1844) Speed up junit tests
Date Thu, 26 Nov 2009 15:38:05 GMT
Despite my long rambling, I agree that speeding things up is worthwhile.
Just
not a huge deal for some of us poor peons who are on dinky little 2-core
machines and feel inadequate even *talking* to people who have *real*
machines <G>...

Time to go get ready to eat Turkey....

Erick

On Thu, Nov 26, 2009 at 9:02 AM, Mark Miller <markrmiller@gmail.com> wrote:

>  right - as soon as you have to start running the tests often enough, any
> decent savings turns into less waiting and more work. Waiting for tests to
> run is time that could be better spent elsewhere. And many of us runthe
> tests *a lot* considering how long they take. And we will only keep adding
> more and will continue to do so.
>
> Also, many of us *are* on multicore and should be able to benifit from it.
> I don't dev on anything less than 4 cores these days. It's a life changer :)
> and cheap currently. I'd like 8.
>
> - Mark
>
> http://www.lucidimagination.com (mobile)
>
>
> On Nov 26, 2009, at 5:24 AM, Michael McCandless <lucene@mikemccandless.com>
> wrote:
>
>  I still think there's value to faster tests, even if they don't become
>> so fast as to enable "fully interactive testing".
>>
>> Plus, this is an ongoing goal with time, not a one-time event.  As we
>> create tests we should generally try to maximize coverage and minimize
>> CPU cost, as long as the effort is smallish.
>>
>> Mike
>>
>> On Wed, Nov 25, 2009 at 9:32 PM, Erick Erickson <erickerickson@gmail.com>
>> wrote:
>>
>>> I posted a rather long diatribe outlining why I think speed-ups
>>> are a false goal for Lucene. Briefly, I'm convinced that as long
>>> as the tests are run when Hudson builds Lucene, 99% of the
>>> value of unit tests is realized. I suppose this implies that the
>>> hard-core committers agree that as long as failed tests
>>> are caught/corrected within a day things are fine.
>>>
>>> Although coming from a background where unit
>>> tests are not always required, my viewpoint may be
>>> suspect <G>.
>>>
>>> Erick@NotToBeConfusedWithHatcher.com....
>>>
>>> On Wed, Nov 25, 2009 at 8:43 PM, Michael McCandless (JIRA)
>>> <jira@apache.org>wrote:
>>>
>>>
>>>>   [
>>>>
>>>> https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782716#action_12782716
>>>> ]
>>>>
>>>> Michael McCandless commented on LUCENE-1844:
>>>> --------------------------------------------
>>>>
>>>> Will we also speed up back-compat tests?
>>>>
>>>>  Speed up junit tests
>>>>> --------------------
>>>>>
>>>>>                Key: LUCENE-1844
>>>>>                URL: https://issues.apache.org/jira/browse/LUCENE-1844
>>>>>            Project: Lucene - Java
>>>>>         Issue Type: Improvement
>>>>>           Reporter: Mark Miller
>>>>>        Attachments: FastCnstScoreQTest.patch,
>>>>>
>>>> hi_junit_test_runtimes.png, LUCENE-1844.patch
>>>>
>>>>>
>>>>>
>>>>> As Lucene grows, so does the number of JUnit tests. This is obviously
a
>>>>>
>>>> good thing, but it comes with longer and longer test times. Now that we
>>>> also
>>>> run back compat tests in a standard test run, this problem is
>>>> essentially
>>>> doubled.
>>>>
>>>>> There are some ways this may get better, including running parallel
>>>>>
>>>> tests. You will need the hardware to fully take advantage, but it should
>>>> be
>>>> a nice gain. There is already an issue for this, and Junit 4.6, 4.7 have
>>>> the
>>>> beginnings of something we might be able to count on soon. 4.6 was
>>>> buggy,
>>>> and 4.7 still doesn't come with nice ant integration. Parallel tests
>>>> will
>>>> come though.
>>>>
>>>>> Beyond parallel testing, I think we also need to concentrate on keeping
>>>>>
>>>> our tests lean. We don't want to sacrifice coverage or quality, but I'm
>>>> sure
>>>> there is plenty of fat to skim.
>>>>
>>>>> I've started making a list of some of the longer tests - I think with
>>>>>
>>>> some work we can make our tests much faster - and then with
>>>> parallelization,
>>>> I think we could see some really great gains.
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> You can reply to this email to add a comment to the issue online.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>
>>>>
>>>>
>>> I posted a rather long diatribe outlining why I think speed-ups
>>> are a false goal for Lucene. Briefly, I'm convinced that as long
>>> as the tests are run when Hudson builds Lucene, 99% of the
>>> value of unit tests is realized. I suppose this implies that the
>>> hard-core committers agree that as long as failed tests
>>> are caught/corrected within a day things are fine.
>>>
>>> Although coming from a background where unit
>>> tests are not always required, my viewpoint may be
>>> suspect <G>.
>>>
>>> Erick@NotToBeConfusedWithHatcher.com....
>>>
>>> On Wed, Nov 25, 2009 at 8:43 PM, Michael McCandless (JIRA) <
>>> jira@apache.org> wrote:
>>>
>>>>
>>>>   [
>>>> https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782716#action_12782716
>>>>  ]
>>>>
>>>> Michael McCandless commented on LUCENE-1844:
>>>> --------------------------------------------
>>>>
>>>> Will we also speed up back-compat tests?
>>>>
>>>>  Speed up junit tests
>>>>> --------------------
>>>>>
>>>>>                Key: LUCENE-1844
>>>>>                URL: https://issues.apache.org/jira/browse/LUCENE-1844
>>>>>            Project: Lucene - Java
>>>>>         Issue Type: Improvement
>>>>>           Reporter: Mark Miller
>>>>>        Attachments: FastCnstScoreQTest.patch,
>>>>> hi_junit_test_runtimes.png, LUCENE-1844.patch
>>>>>
>>>>>
>>>>> As Lucene grows, so does the number of JUnit tests. This is obviously
a
>>>>> good thing, but it comes with longer and longer test times. Now that
we also
>>>>> run back compat tests in a standard test run, this problem is essentially
>>>>> doubled.
>>>>> There are some ways this may get better, including running parallel
>>>>> tests. You will need the hardware to fully take advantage, but it should
be
>>>>> a nice gain. There is already an issue for this, and Junit 4.6, 4.7 have
the
>>>>> beginnings of something we might be able to count on soon. 4.6 was buggy,
>>>>> and 4.7 still doesn't come with nice ant integration. Parallel tests
will
>>>>> come though.
>>>>> Beyond parallel testing, I think we also need to concentrate on keeping
>>>>> our tests lean. We don't want to sacrifice coverage or quality, but I'm
sure
>>>>> there is plenty of fat to skim.
>>>>> I've started making a list of some of the longer tests - I think with
>>>>> some work we can make our tests much faster - and then with parallelization,
>>>>> I think we could see some really great gains.
>>>>>
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> You can reply to this email to add a comment to the issue online.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>
>>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

Mime
View raw message