> 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

Reply via email to