ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Virtual FileSystem Layer
Date Sat, 29 Dec 2001 01:56:46 GMT
On Sat, 29 Dec 2001 06:50, Stefan Bodewig wrote:
> On Sat, 22 Dec 2001, Peter Donald <> wrote:
> > JNDI is nice. It will be slower - a lot slower - and a bit more
> > memory hungry ... whether this is an issue or not is another thing
> > altogether.
> This could become a big issue, at least the "a lot slower" part.  All
> the crude "are we doing a slow scan" parts in DirectoryScanner are
> there because Ant 1.1 has simply been too slow when scanning large
> directory trees.  Even now, most time of the javac task will be spent
> scanning the source tree for files that match **/*.java - the
> compilation itself will probably be a lot faster (at least when using
> jikes or modern).  <javac>'s perfomance is one of Ant's big pros, so
> we shouldn't destroy that 8-)
> Any estimate how bad the performance of JNDI compared to direct file
> access is?  Can we implement a hybrid solution that uses direct file
> system access when we know that we are talking about plain local
> files?

A lot of it will come down to how we actually implement things. (ie do we 
keep the JNDI tree in memeory or create objects on demand or whatever). If we 
cached the tree in memory then the speed of JNDI would actually be faster 
that native file access (on most filesystems).

The cost of file access is significantly higher than constructing the JNDI 
tree. It could also be slower (maybe 10%->1% depending on the JVM) due to the 
allocation of lots of objects everytime you look up things and add things to 
tree. FWIW I used to refer to JNDI as a object fountain because of this sort 
of behaviour. 

So I guess it really depends on how it is implemented. We could implement it 
so that it is speedy as but it will always be more memory hungry. So when I 
say slower it is not really in same league as slowscan/fastscan much less. 
All comes down to code-fu.

However the main penalty of JNDI is that it is a generic interface. I don't 
mind it because I have written oodles of providers, and dozens of apps that 
use naming/directory services but it would not be as simple as a custom API.

So JNDI is 
* more memory hungry
* maybe faster or slower depending on implementation
* much more complex an API (but standard so others may already know it).



Ancient Go proverb: "Only amateurs 
try to come up with 'fancy' moves"

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

View raw message