ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [OT] Build Time
Date Tue, 19 Aug 2003 04:36:42 GMT
Stefan Bodewig wrote:

> On Sat, 16 Aug 2003, Costin Manolache <> wrote:
>> Regarding ant logging system - I think we should eventually reopen
>> the subject and pick a logger API
> I fail to see the benefit of using a different logging system, but I'm
> ceratinly open to discuss it.
> Ant's system currently is an event based system which goes beyond
> simple logging and we'd still have to maintain that anyway.  It is
> getting used for much more things than just logging.  AntClassLoader
> uses buildFinished events to deregister and clean itself up to allow
> garbage collection for example.

I know. 

The problem is that we also use this logging system for debug info - 
and IMO at least this doesn't work as well. If you want to find what's wrong
with a build ( and wrong things happen with complex build files ) - you can
enable debug/verbose, but that's far too much info to process. 

Something like log4j would allow us to enable debug on a particular target
or task.

The second issue with using the current event-based system for debug is the 
performance - we need to _allways_ do the string concatenations, and that
may have a significant impact on performance.

>> then start using the normal if( log.isDebugEnabled()) log() that
>> prevents useless string concatenations and calls.
> Vadim's stats say that cloning of the build listener list and
> iterating through them are the problem, not string concatenation.

That's one problem. IMO string concat is also a problem, but it won't show
in OptimizeIt if you do time-based profiles. 

> And I doubt that you could implement isDebugEnabled() at all using
> Ant's BuildListener concept as the listener decides what to log, Ant
> just passes the events along.  It is very well possible that one
> listener will log a MSG_DEBUG message while another one will not - and
> both are there at the same time.

That's exactly the problem. Most of the time the debug messages are not
logged by anyone - and if you need them, usually you need a small set. 
By default that's hard to get, and in the most common use case ( no debug )
it is inefficient.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message