ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Yates <>
Subject Re: Testlistener Events in JUnit Slows Down Forked Tests in 1.8.x
Date Tue, 10 Aug 2010 19:20:43 GMT
Why does the StreamPumper poll like that? Surely it should just block
reading the InputStream?

To deal with InterruptedException, you can just do a timed read and test the
interrupted flag before looping back to the blocking read.


On 10 August 2010 20:00, Stefan Bodewig <> wrote:

> On 2010-08-10, Jesse Glick wrote:
> > On 08/09/2010 03:42 AM, Stefan Bodewig wrote:
> >> I plan to add an disableTestListenerEvents
> > First I would like to hear an explanation of why printing a few lines
> > to System.out causes such a big performance hit and why this cannot be
> > fixed.
> "such a big" is just the accumulation of many small hits.
> A test that takes a few miliseconds without the lines to System.out may
> be unfortunate enough to always print lines just after the StreamPumper
> has entered the sleep call and then must wait until StreamPumper wakes
> up before it can proceed.  There is one such line before and after each
> test method and each stands a chance to hit the POLL_TIMEOUT which is
> 100ms.
> In the very simple test case Laura provided all test together finish in
> less than 10ms and just one of them hitting the sleep is enough to make
> the entire runtime 10 times as much.
> In reality each such line is pretty likely to be written while the
> pumper is sleeping, each line is pretty likely to be delayed by up to
> 100ms, even though it will be a lot shorter than that in most cases.  If
> you have many test, the times sum up.  This isn't anything you notice in
> a testsuite where individual tests take long - like Ant's own testsuite
> whose runtime is dominated by test methods that take many seconds - but
> in setups with very many very small test.
> > Does the problem only occur on Windows?
> In 1.8.0, yes.  In theory the fix for Bug 48746 has ported the effect to
> any OS with Ant 1.8.1 but I've been unable to see the effect on Linux -
> at least with Laura's small testcase.  I must admit I haven't tried it
> again on any OS but Windows after I figured out what was going on.
> > And can it be avoided by just removing calls to flush(),
> No, that doesn't have any effect.  Thinking of it, buffering on the
> testrunner side would help but at the same time make the lines unusable
> for the test listener events that must happen in step with the test to
> be useful.
> > possibly using System.err?
> Uses a different StreamPumper instance but would suffer from the same
> effect.
> >> We could add a YAMP (yet another magic property) ...
> > This would be much preferable IMHO. The property would just be set by
> > any container which wants to listen to <junit> progress.  (An
> > attribute in the build script is useless for this purpose, even if the
> > default is on - since the user might turn it off for speed of builds
> > in other environments!)
> You mean the magic property would enable the events even if the user
> wants to turn them off?  Or do you want to turn events off by default
> and enable them based on the magic property?  The later would break
> backwards compatibility.
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message