[PATCH 1 of 3 v4] store: implement fncache path mangling code in C
pierre-yves.david at ens-lyon.org
Fri Sep 7 16:39:42 CDT 2012
On 7 sept. 2012, at 22:10, Bryan O'Sullivan wrote:
> On Fri, Sep 7, 2012 at 12:45 PM, Adrian Buehlmann <adrian at cadifra.com> wrote:
> What I still don't understand is, why is it worth the risk (and the effort) here?
> Because I don't want Mercurial to act slow for arbitrary reasons. If I implemented only the fast encoding in C, we'd be left in a situation where sometimes the performance would be good, sometimes bad, and this would depend on the conventions around naming in a particular repo. This is both hard to understand and difficult to justify to users.
> I'm not thrilled to have both code paths duplicated, but I think it's worth it to give a more uniform experience.
I'm a bit surprised that such an critical part of the windows ecosystem do not have canonical an exhaustive test sets.
If it is that hard to validate this new C version, maybe we could crowd source this part:
(1) 2.4 with a C version unused by default
(2) add a option to compute fncache with both Python and C version and report mismatch
(3) Ask our baroque windows user to turn it on.
That would be a shame to refuse this significant performance improvement.
More information about the Mercurial-devel