Correction - the timings are actually done for Xalan runs, so the
numbers below are not the right ones. The actual slowness happens just
before Xalan call, as described by Holger. Nevertheless I can see at
least 50x speedup for the reports (on Linux - 3 seconds with the patch
vs 170 seconds without)
Andrus
On Wednesday, April 2, 2003, at 10:52 PM, Andrus Adamchik wrote:
> Holger,
>
> looks like your Ant patch is doing its magic. Report generation time
> is down to 14 sec on 1.8 GHz Linux and 60 sec on a 800MHz PowerBook
> Mac OS X! Now this is bearable (esp. 14 sec. :-)). On my part I
> reorganized the build file to allow forcing test reports even if no
> failures occurred (use another property: -Dcayenne.test.report=true).
> This will be useful for things like nightly builds.
>
> I submitted bug report to Ant team, but it was closed without
> investigation. They were simply reluctant to fix other's bugs, so
> nobody even bothered to look into the suggested fix. Oh well, we did
> our part, what do we care now.
>
> Andrus
>
>
>
> On Sunday, March 30, 2003, at 11:55 AM, Andrus Adamchik wrote:
>> On Sunday, March 30, 2003, at 09:00 AM, Holger Hoffstätte wrote:
>>
>>> - I look into ant's DOMElementWriter and see a shared StringBuffer
>>> ivar sb
>>> that seems to be reused. An alarm bell goes off. Every written DOM
>>> element
>>> string is mangled via encode(), where I see that the shared
>>> StringBuffer
>>> is first set to size 0, then filled, then at the very end - the
>>> terrible
>>> toString() happens. I replace toString() with substring(0,
>>> sb.length()),
>>> run the unit test suite and start to create all reports.
>>>
>>> - KABOOM! ** _1_ second ** for collecting all tests into the single
>>> XML
>>> file before feeding it into Xalan (which takes its usual 9 seconds).
>>> Yes,
>>> the generated output is still correct.
>>>
>>> Any suggestion about what to do now? Could someone please take the
>>> time to
>>> report both the output buffering and toString() problems to the ant
>>> folks?
>>> I just checked the ant 1.5.3rc1 source and it's still in there. Btw,
>>> regarding ant: 1.5.2 creates 'broken' archives; I'll see that we get
>>> 1.5.3
>>> into cvs as soon as it's released (and verifiably works).
>>>
>>> If they refuse to fix this for whatever political reasons I can pack
>>> up a
>>> little ant-fix.jar, so that we don't waste more time waiting for
>>> reports.
>>>
>>> Holger
>>>
>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Wed Apr 02 2003 - 23:11:28 EST