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. Danny. On 10 August 2010 20:00, Stefan Bodewig <bode...@apache.org> 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: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
