[PATCH] V13 of experiment for a simpler path encoding for hashed paths (for "fncache2")

[Adrian Buehlmann]

On 2012-09-29 14:34, Adrian Buehlmann wrote:
> On 2012-09-29 11:29, Adrian Buehlmann wrote:
>> # HG changeset patch
>> # User Adrian Buehlmann <adrian at cadifra.com>
>> # Date 1348910761 -7200
>> # Node ID ca5bca5255271ae28320c4d107b11ba5c9dab1de
>> # Parent  d6c7128e550de7d74aec27e86532ceec75a5c38f
>> V13 of experiment for a simpler path encoding for hashed paths (for "fncache2")
> 
> I was a bit curious and looked at the assembly code created by the MS C compiler.
> 
> I used this temporary hack:
> 
> diff --git a/setup.py b/setup.py
> --- a/setup.py
> +++ b/setup.py
> @@ -422,7 +422,8 @@
>      Extension('mercurial.diffhelpers', ['mercurial/diffhelpers.c']),
>      Extension('mercurial.mpatch', ['mercurial/mpatch.c']),
>      Extension('mercurial.parsers', ['mercurial/parsers.c',
> -                                    'mercurial/pathencode.c']),
> +                                    'mercurial/pathencode.c'],
> +                                   extra_compile_args=["/FAs"]),
>      ]
>  
>  osutil_ldflags = []
> 
> 
> I pasted the (hopefully) relevant part here:
> http://pastebin.com/Pjr4N9h3

I'm surprised to see that memcpy is *called*, not inlined. memcpy should
be an intrinsic and the command line options for the compiler (cl.exe)
are set correctly (/Ox which implies /Oi [1]).

The compiler is the one from the SDK
http://www.microsoft.com/en-us/download/details.aspx?id=3138

I was under the impression that it's the optimzing one. At least it
inlines functions, e.g. our own memcopy function appears to get inlined
as expected, but not the call to memcpy inside it.

[1] http://msdn.microsoft.com/en-us/library/26td21ds(v=vs.90).aspx