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
