PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2 small changes to consider
This patch adds wildcard support to file::exists(). Basically it uses DirectoryScanner to find matching files. Is it ok to commit it ? Jarek fileexists.patch Description: Binary data
Re: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2 small changes to consider
Speed? Of course it's possible to always use the scanner and I can change
it.
Jarek
- Original Message -
From: Scott Hernandez [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]; Hemry, Jeff
[EMAIL PROTECTED]
Cc: ! nant [EMAIL PROTECTED]
Sent: Friday, February 27, 2004 8:27 PM
Subject: Re: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2
small changes to consider
Is there any reason that you don't always use the scanner?
if (file.IndexOf(*) != -1 || file.IndexOf(?) != -1) {
...
} else
return File.Exists(Project.GetFullPath(file));
Less code paths, etc... :)
- Original Message -
From: Jaroslaw Kowalski [EMAIL PROTECTED]
To: Hemry, Jeff [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Friday, February 27, 2004 11:13 AM
Subject: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2
small
changes to consider
This patch adds wildcard support to file::exists(). Basically it uses
DirectoryScanner to find matching files.
Is it ok to commit it ?
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=1356alloc_id=3438op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: PATCH: file::exists() wildcard support, WAS: Re: [nant-dev] 2 small changes to consider
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=1356alloc_id=3438op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
