On Mar 19, 2007, at 4:17 AM, Nicholas Clark wrote:
On Sun, Mar 18, 2007 at 08:33:25PM -0700, Joshua Juran wrote:
I can't imagine someone else hasn't already come up with
cnv = path->strstart;
while ( (cnv = strchr( cnv, '/' )) )
{
*cnv = '\\';
}
but I didn't see it posted, so here it is just in case.
Bikesheds, I know, but this will be faster:
cnv = path->strstart;
while ( (cnv = strchr( cnv, '/' )) )
{
*cnv++ = '\\';
}
because there's no way that the character at cnv can match '/' now :-)
I agree that that condition holds, but I'm not convinced your
optimization yields a speed increase. It saves a byte comparison per
match, (which I missed before) but it doesn't prevent any calls to
strchr(). And it makes the code a tiny bit larger, and a tiny bit
more complex. I'd probably go with yours over mine for
'correctness'[1], though, unless profiling indicated otherwise.
[1] Regardless of speed, it 'looks' wasteful to duplicate that byte
comparison. It's usually important that the reader of the code have
confidence in it.
Anyway, your performance claim is a load of null if the pathname
conversion is followed by a filesystem operation such as stat(). :-)
Whether its faster than the loop without strchr probably depends on
whether
the compiler inlines strchr(), whether the optimised version is
efficient
on non-word aligned strings, and whether the optimised version
doesn't have
a higher start cost. Either is better* than the current, and I
don't have
a Win32 platform to test on, so can't test a change.
Nicholas Clark
* Yes, even in a non-speed critical area, because having poor
algorithms around
will tempt people to base other code on them.
Josh
