> Yeah, I'm sure we all go back and forward on this issue. Performance is > important, and we should strive towards it, but I have found that sometimes > what seems like a performance tweak turns out to not work out as I expect. > I'm sure the scanner is slower than file.exists, but in this case I would > lean towards less code paths, and leave the performance issues till we start > to see a problem. Profiling nant will most likely result in all kinds of hot > spots. If this is an issue, changing it will be important. It may even be > that we tune the scanner to check for the special case of a file without any > wildcards, then the overhead is just a few objects and a virtual method > calls, as compared to just the file.exists call. I'm sure the slowest part > of all this, by far, is the io operation to check for the file. > > This is really more of a general question as to whether we should code for > less code paths (simpler code?) or try to write with performance in mind. > I'm leaning towards less code paths... :)
It's fine with me, really ;-) Jarek ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers