Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 3054 invoked from network); 25 Nov 2009 19:13:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Nov 2009 19:13:17 -0000 Received: (qmail 70356 invoked by uid 500); 25 Nov 2009 19:13:16 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 70264 invoked by uid 500); 25 Nov 2009 19:13:16 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 70256 invoked by uid 99); 25 Nov 2009 19:13:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Nov 2009 19:13:16 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of erickerickson@gmail.com designates 209.85.220.224 as permitted sender) Received: from [209.85.220.224] (HELO mail-fx0-f224.google.com) (209.85.220.224) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Nov 2009 19:13:13 +0000 Received: by fxm24 with SMTP id 24so27884fxm.11 for ; Wed, 25 Nov 2009 11:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=fmJSYtzYhSbE8cNDwKAPJMrsI3FtO18vksPvASZgMyU=; b=bbZvZZSMjhs4B+PYlWYH5h5Dohc2/KRkJr6lUL+GNUmEYveip34JzQjhiy9DJCAjhN sOpaPY511NfX4iz6Y3ao/7V96Y9rs0yuvbhi4R2aKj8/kLevkErzoM3OCWiOry6b8ZEW X6b7q1JVrhPCOMheMkh6lvh2cqZwLISU86Oio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Eoj3UVt4sBkLPsgOj8p5puBEaFKkVd23k1ZAqoaG1nYeaoHtFsHLSnp5L+KnVRE8i1 762mlIta4Zm9XOrUisaS/8ljkaXYUjAOEM42OG1Hm2Vy7ZiTTS4kqjoyYoodA43VXlSO dhWtX5anjDDq3lufyxEmDXnRTwEbrVME55p9g= MIME-Version: 1.0 Received: by 10.216.85.5 with SMTP id t5mr2618497wee.142.1259176371177; Wed, 25 Nov 2009 11:12:51 -0800 (PST) In-Reply-To: <4B0D7400.6010003@gmail.com> References: <1450923845.1250989154859.JavaMail.jira@brutus> <1829560948.1259167779624.JavaMail.jira@brutus> <359a92830911251001o573d59cfie22cfaf3ace3c0e1@mail.gmail.com> <4B0D7400.6010003@gmail.com> Date: Wed, 25 Nov 2009 14:12:51 -0500 Message-ID: <359a92830911251112mb6bb2fencff622b3551a9f7a@mail.gmail.com> Subject: Re: [jira] Commented: (LUCENE-1844) Speed up junit tests From: Erick Erickson To: java-dev@lucene.apache.org Content-Type: multipart/alternative; boundary=0016e6d64861504ce6047936d80e --0016e6d64861504ce6047936d80e Content-Type: text/plain; charset=ISO-8859-1 Hmmm, the patches that I supplied for Junit4 *require* 4.7 anyway, which I included in the patch... Is this a problem? Or just a document problem? Erick On Wed, Nov 25, 2009 at 1:14 PM, Mark Miller wrote: > junit 4 parallelization is still in its infancy. I think the docs for it > are just in the changes file that it was first released with. That > version had severe bugs that made it almost unusable - I think thats > mostly fixed in a newer release. There is also a much better impl of one > of the key classes (I think they call it computer) written by someone > else that will eventually go into the code base I think (written by the > guy(s) that I think found/fixed the initial buggy-ness) - essentially, I > think its still unbaked. > > Here are some docs from the release notes of 4.6: > > http://sourceforge.net/project/shownotes.php?release_id=675664&group_id=15278 > > Thats also an issue - it arrived only in 4.6 - so this would need to be > optional unless we bumped up our req from 4 - and it really requires at > least 4.7 for the fixes (if everything is even fixed). > > You also have to setup which tests run in parallel by hand essentially. > No ant task to help with this last I looked. So it will probably end up > being an alternate way to run the tests initially (at best). > > - Mark > > Erick Erickson wrote: > > They're ready to go, but at Uwe's suggestion, I've been waiting for > > 3.0 to get settled before prompting someone to apply this patch. I was > > going to generate a new patch for this and for 2037 (junit4 tests) > > just to make sure they were easy to apply. But if you're willing, the > > patches are already attached to the JIRA issues. Do note that the > > decision in MinBooleanShouldMatch to stop checking the query after 100 > > rather than checking all 1,000 is included in the patch.... > > > > Do you want to apply the patches or should I regenerate? It's no big > > deal to regenerate them and I'll have a better feel for reconciling > > any conflicts. I don't know whether there even *are* any conflicts, > > but just in case.... > > > > For my info, though, if I have a more recent patch that *replaces* an > > earlier patch, especially one that hasn't yet been applied, is it > > preferred to delete the earlier patch when providing a new one? > > > > I'm not pleased with the Junit4 documentation, most of what I've been > > able to glean has come from brave souls blogging. Does anyone have a > > gold mine or is it as hit-or-miss as I think? There are hints of > > parallelization capabilities in Junit4, but I'm having a hard time > > finding anything in much depth..... The Junit website is pathetic, I > > can't even find 4.7 javadocs, it keeps giving me 4.5, as evidenced by > > no @Rule docs or @Intercept. And no version information in the > > javadocs..... Or I'm completely missing the boat.... I was thinking > > about getting the entire project over the weekend and generating my > > own if I have the time > > > > Erick > > > > On Wed, Nov 25, 2009 at 11:49 AM, Michael McCandless (JIRA) > > > wrote: > > > > > > [ > > > https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782497#action_12782497 > > < > https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782497#action_12782497 > > > > ] > > > > Michael McCandless commented on LUCENE-1844: > > -------------------------------------------- > > > > Is this ready to go in? I'd really love to see unit tests run > > faster :) > > > > > 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 > > --0016e6d64861504ce6047936d80e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hmmm, the patches that I supplied for Junit4 *require* 4.7 anyway, whichI included in the patch... Is this a problem? Or just a document problem?=

Erick

On Wed, N= ov 25, 2009 at 1:14 PM, Mark Miller <markrmiller@gmail.com> wrote:
junit 4 parallelization is still in its inf= ancy. I think the docs for it
are just in the changes file that it was first released with. That
version had severe bugs that made it almost unusable - I think thats
mostly fixed in a newer release. There is also a much better impl of one of the key classes (I think they call it computer) written by someone
else that will eventually go into the code base I think (written by the
guy(s) that I think found/fixed the initial buggy-ness) - essentially, I think its still unbaked.

Here are some docs from the release notes of 4.6:
http://sourceforge.net/project/sho= wnotes.php?release_id=3D675664&group_id=3D15278

Thats also an issue - it arrived only in 4.6 - so this would need to be
optional unless we bumped up our req from 4 - and it really requires at
least 4.7 for the fixes (if everything is even fixed).

You also have to setup which tests run in parallel by hand essentially.
No ant task to help with this last I looked. So it will probably end up
being an alternate way to run the tests initially (at best).

- Mark

Erick Erickson wrote:
> They're ready to go, but at Uwe's suggestion, I've been wa= iting for
> 3.0 to get settled before prompting someone to apply this patch. I was=
> going to generate a new patch for this and for 2037 (junit4 tests)
> just to make sure they were easy to apply. But if you're willing, = the
> patches are already attached to the JIRA issues. Do note that the
> decision in MinBooleanShouldMatch to stop checking the query after 100=
> rather than checking all 1,000 is included in the patch....
>
> Do you want to apply the patches or should I regenerate? It's no b= ig
> deal to regenerate them and I'll have a better feel for reconcilin= g
> any conflicts. I don't know whether there even *are* any conflicts= ,
> but just in case....
>
> For my info, though, if I have a more recent patch that *replaces* an<= br> > earlier patch, especially one that hasn't yet been applied, is it<= br> > preferred to delete the earlier patch when providing a new one?
>
> I'm not pleased with the Junit4 documentation, most of what I'= ve been
> able to glean has come from brave souls blogging. Does anyone have a > gold mine or is it as hit-or-miss as I think? There are hints of
> parallelization capabilities in Junit4, but I'm having a hard time=
> finding anything in much depth..... The Junit website is pathetic, I > can't even find 4.7 javadocs, it keeps giving me 4.5, as evidenced= by
> no @Rule docs or @Intercept. And no version information in the
> javadocs..... Or I'm completely missing the boat.... I was thinkin= g
> about getting the entire project over the weekend and generating my > own if I have the time
>
> Erick
>
> On Wed, Nov 25, 2009 at 11:49 AM, Michael McCandless (JIRA)
> <jira@apache.org <mailto:jira@apache.org>> wrote:
>
>
> =A0 =A0 =A0 =A0[
> =A0 =A0 https://issu= es.apache.org/jira/browse/LUCENE-1844?page=3Dcom.atlassian.jira.plugin.syst= em.issuetabpanels:comment-tabpanel&focusedCommentId=3D12782497#action_1= 2782497
> =A0 =A0 <https://= issues.apache.org/jira/browse/LUCENE-1844?page=3Dcom.atlassian.jira.plugin.= system.issuetabpanels:comment-tabpanel&focusedCommentId=3D12782497#acti= on_12782497>
> =A0 =A0 ]
>
> =A0 =A0 Michael McCandless commented on LUCENE-1844:
> =A0 =A0 --------------------------------------------
>
> =A0 =A0 Is this ready to go in? =A0I'd really love to see unit tes= ts run
> =A0 =A0 faster :)
>
> =A0 =A0 > Speed up junit tests
> =A0 =A0 > --------------------
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Key: LUCENE-1844
> =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 URL:
> =A0 =A0 https://issues.apache.org/jira/browse/LUCENE-1844
> =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 Project: Lucene - Java
> =A0 =A0 > =A0 =A0 =A0 =A0 =A0Issue Type: Improvement
> =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0Reporter: Mark Miller
> =A0 =A0 > =A0 =A0 =A0 =A0 Attachments: FastCnstScoreQTest.patch, > =A0 =A0 hi_junit_test_runtimes.png, LUCENE-1844.patch
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > As Lucene grows, so does the number of JUnit tests. This = is
> =A0 =A0 obviously a good thing, but it comes with longer and longer te= st
> =A0 =A0 times. Now that we also run back compat tests in a standard te= st
> =A0 =A0 run, this problem is essentially doubled.
> =A0 =A0 > There are some ways this may get better, including runnin= g
> =A0 =A0 parallel tests. You will need the hardware to fully take
> =A0 =A0 advantage, but it should be a nice gain. There is already an i= ssue
> =A0 =A0 for this, and Junit 4.6, 4.7 have the beginnings of something = we
> =A0 =A0 might be able to count on soon. 4.6 was buggy, and 4.7 still > =A0 =A0 doesn't come with nice ant integration. Parallel tests wil= l come
> =A0 =A0 though.
> =A0 =A0 > Beyond parallel testing, I think we also need to concentr= ate on
> =A0 =A0 keeping our tests lean. We don't want to sacrifice coverag= e or
> =A0 =A0 quality, but I'm sure there is plenty of fat to skim.
> =A0 =A0 > I've started making a list of some of the longer test= s - I think
> =A0 =A0 with some work we can make our tests much faster - and then wi= th
> =A0 =A0 parallelization, I think we could see some really great gains.=
>
> =A0 =A0 --
> =A0 =A0 This message is automatically generated by JIRA.
> =A0 =A0 -
> =A0 =A0 You can reply to this email to add a comment to the issue onli= ne.
>
>
> =A0 =A0 --------------------------------------------------------------= -------
> =A0 =A0 To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> =A0 =A0 <mailto:java-dev-unsubscribe@lucene.apache.org>
> =A0 =A0 For additional commands, e-mail: java-dev-help@lucene.apache.org=
> =A0 =A0 <mailto: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


--0016e6d64861504ce6047936d80e--