Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
From: Stefan Bodewig <bodewig@apache.org>
To: dev@ant.apache.org
Subject: Re: Testlistener Events in JUnit Slows Down Forked Tests in 1.8.x
References: <87vd7ks04x.fsf@v35516.1blu.de> <i3s5fg$omj$1@dough.gmane.org>
Date: Tue, 10 Aug 2010 21:00:03 +0200
In-Reply-To: <i3s5fg$omj$1@dough.gmane.org> (Jesse Glick's message of "Tue, 10
	Aug 2010 14:23:42 -0400")
Message-ID: <878w4el2do.fsf@v35516.1blu.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org