[PATCH] fix regression reported in 1286

Matt Mackall mpm at selenic.com
Tue Sep 9 13:40:42 CDT 2008


On Sat, 2008-09-06 at 08:02 -0400, Petr Kodl wrote:
> as for the micro optimization - I timed both - at least on my Core 2 box 
> the get seemed to be a bit better in several loops but I do not hang on it
> The 'in' based code looks cleaner - it just seemed a bit counter 
> intuitive that two dictionary lookups would be faster than one - in 
> positive case.
> 
> As for for the norm_path - you are right - returning path instead of 
> normalized version is the correct thing to do.
> There is one interesting side effect - returning norm_path on large tree 
> - albeit technically incorrect, is for some reason measurably faster on 
> large trees - 30-50%. I'll try to figure out why - but it all happes in 
> second step of walk.
> 
> We should be able to drop the normpath from the normpath(normcase()) 
> expression safely
> 
> 1) It is quite expensive to call
> 2) The normcase already does both case and / -> \ translation so the 
> only job left for normpath is the redundant component collapsing, but 
> that should not be required - as we do not do it on Unix either
> So technically dropping the normpath should make the behavior more 
> consistent between non-folding and folding OS versions with respect to 
> path components like a/../a

Gah, top-posting. I said:

> > Also, returning the normcase'd version here looks just wrong.

We never want to return the normcase'd version as that's approximately
path.lower(). In other words, not what's on disk. We -do- want to
normpath version as that fixes up stuff like /../.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list