This is probably a better idea as it allows fine-grained control (i.e. excluding just tight loops)?
Dawid On Thu, Apr 19, 2012 at 10:15 AM, Uwe Schindler <u...@thetaphi.de> wrote: > To disable clover for heavy tests, we can use (its just a code comment to be > included, that tells the instrumenter to disable coverage for this code part > between the comments): > > http://goo.gl/ZohAv > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -----Original Message----- >> From: Uwe Schindler [mailto:u...@thetaphi.de] >> Sent: Thursday, April 19, 2012 9:47 AM >> To: dev@lucene.apache.org >> Subject: RE: [JENKINS] Lucene-trunk - Build # 1899 - Failure >> >> Hi, >> >> Maybe TestNRQ does not like SimpleText (it seeks heavily), so maybe thats the >> reason (we should check that with the seed) and add assume. Do other MTQ >> tests allow SimpleText (like Fuzzy, which is also heavy)? With Clover the NRQ >> tests then gets *very* slow. Compare with TestNRQ32, which succeeded in a >> few seconds on the same run, just because of different random settings. >> >> Because of the instrumentation level per statement, all tight loops take >> forever >> with clover. But changing to "method" level removes all the interesting >> information for us. We could also add a @NoClover annotation. We would need >> no sysprops for that, it would be enough to do a Class.forName on any of the >> clover classes to find out if clover is "active" for the current test run. >> >> Maybe we should raise the JVM setting for the code cache when running with >> clover, because clover-instrumented class files are a lot more "complex" for >> hotspot. >> >> ----- >> Uwe Schindler >> H.-H.-Meier-Allee 63, D-28213 Bremen >> http://www.thetaphi.de >> eMail: u...@thetaphi.de >> >> >> > -----Original Message----- >> > From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf >> > Of Dawid Weiss >> > Sent: Thursday, April 19, 2012 9:38 AM >> > To: dev@lucene.apache.org >> > Subject: Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure >> > >> > I'll try to inspect later today why these are so slow in that run: >> > >> > [junit4] <JUnit4> says g'day! Master seed: C26BAC36B9BF265D >> > >> > [junit4] Suite: org.apache.lucene.index.TestByteSlices >> > [junit4] Completed in 1852.84s, 1 test >> > >> > [junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64 >> > [junit4] Completed in 4251.28s, 34 tests >> > >> > Dawid >> > >> > On Thu, Apr 19, 2012 at 9:28 AM, Dawid Weiss >> > <dawid.we...@cs.put.poznan.pl> wrote: >> > >> I have seen this on jenkins several times (especially with Clover >> > instrumentation). In this case instrumentation was running. >> > > >> > > Clover is a hog, we've experienced that too. >> > > >> > >> I think its caused by too many instrumentation (per statement) in >> > >> heavy tests >> > like TestNRQ or similar. Unfortunately we don’t see here, which test >> > exactly was leading to this output. >> > > >> > > I don't think you'd be able to see that precisely anyway because >> > > these are printed to two different stream buffers -- it bypasses >> > > Java's PrintStreams and dumps directly to the original file descriptor. >> > > >> > > Dawid >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For >> > additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional >> commands, e-mail: dev-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
