On Tue, 1 Nov 2016 16:17:57 +0000, Jun Wu wrote: > Excerpts from Pierre-Yves David's message of 2016-11-01 16:59:36 +0100: > > So, just to confirm, the performance impact will only show up in case > > where we would have raised and ambiguity error anyway ? So in the only > > behavior/performance impact we'll see is a move from an abort to a > > slightly slower lookup. Am I right ? > > Yes. But the slower (much much slower) lookup is likely to end up with the > same abort error. For example, if the user types a very short hash, which is > definitely causing a ambiguity, the old code would return instantly, where > the new one will be slowed down very much. > > Some places even use unfiltered repo as a workaround for the performance > issue: > > > https://www.mercurial-scm.org/repo/hg/file/cac4ca036dff/mercurial/templater.py#l840
Just to make sure, shortest() must avoid the O(N) lookup since it exists in the common code path, which is different from changectx.__init__(). But I'm okay to drop this for now, and fix both shortest() and changectx() properly. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
