[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