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 <markrmil...@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 <luc...@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 <erickerick...@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>. >>> >>> er...@nottobeconfusedwithhatcher.com.... >>> >>> On Wed, Nov 25, 2009 at 8:43 PM, Michael McCandless (JIRA) >>> <j...@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-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: java-dev-h...@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>. >>> >>> er...@nottobeconfusedwithhatcher.com.... >>> >>> On Wed, Nov 25, 2009 at 8:43 PM, Michael McCandless (JIRA) < >>> j...@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-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: java-dev-h...@lucene.apache.org >>>> >>>> >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
