--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Sat, 22 Dec 2001, Peter Donald <[EMAIL PROTECTED]> > 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? >
JNDI is an empty shell. It all depends on the implementation of the providers. They can be very smart or they can be very stupid. For example the directory search capabilities of JNDI can be implemented in a provider so that it understands �**� and so on directly and evaluates them on the native provider code (smart) or it can be scanning and creating JNDI objects which are filtered after being created (stupid). The problem with JNDI is that it is easy to write stupid providers, and it could be hard work to implement smart ones. Jose Alberto __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
