<div dir="ltr"><br><br><div class="gmail_quote">On Fri, May 8, 2015 at 7:37 AM Augie Fackler <<a href="mailto:raf@durin42.com">raf@durin42.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, May 07, 2015 at 11:02:20PM -0700, Kyle Lippincott wrote:<br>
> On Thursday, May 7, 2015, Martin von Zweigbergk <<a href="mailto:martinvonz@google.com" target="_blank">martinvonz@google.com</a>><br>
> wrote:<br>
><br>
> ><br>
> > On Thu, May 7, 2015 at 4:34 PM Martin von Zweigbergk <<br>
> > <a href="mailto:martinvonz@google.com" target="_blank">martinvonz@google.com</a><br>
> > <javascript:_e(%7B%7D,'cvml','<a href="mailto:martinvonz@google.com" target="_blank">martinvonz@google.com</a>');>> wrote:<br>
> ><br>
> >> On Thu, May 7, 2015 at 4:27 PM Adrian Buehlmann <<a href="mailto:adrian@cadifra.com" target="_blank">adrian@cadifra.com</a><br>
> >> <javascript:_e(%7B%7D,'cvml','<a href="mailto:adrian@cadifra.com" target="_blank">adrian@cadifra.com</a>');>> wrote:<br>
> >><br>
> >>> On 2015-05-08 00:56, Martin von Zweigbergk wrote:<br>
> >>> > Heh, Drew actually suggested "meta" just so we could avoid dealing with<br>
> >>> > this inconsistency between native and pure code.<br>
> >>><br>
> >>> Yes, please.<br>
> >>><br>
> >><br>
> >> I don't mind changing to "meta", but I'm still concerned about the<br>
> >> discrepancy between native and pure code. Do you have a test case that<br>
> >> shows that performance really is a problem?<br>
> >><br>
> ><br>
> > My crude timings suggest that the ~2k calls to hashencode() on the Firefox<br>
> > repo (~2k files out of ~200k have long names) take ~6ms, while the ~2k<br>
> > calls to strchr() take ~12us. So I'd say the performance argument does not<br>
> > exist and we just have to pick a name that we like.<br>
> ><br>
> > I don't particularly care what name we pick -- "metadata" and "meta" are<br>
> > both fine with me.  Another obvious choice is "manifests", but I know Kyle<br>
> > (CC'd) prefers "metadata" in case we ever want to store something else per<br>
> > directory that's not a manifest. Even though we don't even have any plans<br>
> > for anything else, I see little argument for "manifests" over "meta(data)".<br>
> ><br>
><br>
> I'm fine with meta.  As mentioned it has the benefit of being equal in<br>
> length, and so yeah you can copy the logic over to the pure code to just<br>
> strip 5.   I agree that the discrepancy is the more annoying issue, so I'm<br>
> fine with whatever solution gets applied, just make them consistent.<br>
<br>
+1 - as long as at the end of this exercise the pure and c code do the<br>
same thing, I don't care much what that thing is.<br></blockquote><div><br></div><div>It seems like most of us are the same page regarding getting rid of the discrepancy, but it's still not clear what I'm supposed to do. I think we should leave the decision on the name until we have agreed on the below. Here are some alternatives:</div><div><br></div><div>Stripping 5 characters (what the C code currently does):</div><div>* metadata/ files get stored in dh/ata/</div><div>* If "ata/" sounds funny, just use "meta" instead of "metadata" and we won't notice it (but it's still a silly limitation)</div><div>* Fix is smaller (a net change of 0 bytes)</div><div>* Makes pure code slower (but no one sane runs pure code)</div><div><br></div><div>Stripping top directory (what the Python code currently does):</div><div>* metadata/ files get stored in dh/</div><div>* Stripping a full directory just seems like a more natural thing to do</div><div>* Makes hashencode() ~0.2% slower (but if we are really worried about performance, we should store all non-data/ files using just the hash as filename and not bother with_encodedir,_lowerencode, auxencode)</div><div><br></div><div>Stripping top directory if it doesn't start with 'd':</div><div><div>* metadata/ files get stored in dh/metadata/</div></div><div>* Simple fix needed in both C and Python</div><div>* Probably slows down hashencode() by ~0.01% (my guess, based on 50 clock cycles -> 3) for data/ paths. Probably slows down non-data paths more, since_encodedir,_lowerencode, auxencode have to run also on the "metadata/" part.</div><div><br></div><div>Matt, could you make a decision on this?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
><br>
> > If you do, I could move the patch to the pure side (to strip exactly 5<br>
> >> characters). If not, I'd still prefer to have this patch applied, but it's<br>
> >> up to Matt in the end, of course.<br>
> >><br>
> ><br>
> > Matt, as explained above, I personally think this patch is still good.<br>
> ><br>
> ><br>
> >><br>
> >><br>
> >><br>
> >>><br>
> >>> (I already like Drew)<br>
> >>><br>
> >><br>
<br>
> _______________________________________________<br>
> Mercurial-devel mailing list<br>
> <a href="mailto:Mercurial-devel@selenic.com" target="_blank">Mercurial-devel@selenic.com</a><br>
> <a href="http://selenic.com/mailman/listinfo/mercurial-devel" target="_blank">http://selenic.com/mailman/listinfo/mercurial-devel</a><br>
</blockquote></div></div>