[PATCH 6 of 8] hidden: remove _consistencyblockers()

Martin von Zweigbergk martinvonz at google.com
Sat Jun 3 13:05:06 EDT 2017


On Jun 3, 2017 9:49 AM, "Jun Wu" <quark at fb.com> wrote:

Excerpts from Pierre-Yves David's message of 2017-06-03 14:57:07 +0200:
>
> On 05/30/2017 07:47 PM, Jun Wu wrote:
> > Excerpts from Pierre-Yves David's message of 2017-05-29 19:16:06 +0200:
> >> Ho, this is not a set‽ (that is what I've been missing).
> >>
> >> Hum, we should probably stick to pure python set for the return of
> >> phasecase here and only upgrade them to smartset in revset.
> >
> > smartset is better because:
> >
> >   - smartset is ordered. If we return a set, some code paths still sort
> >     them, which is a waste of time.
> >   - smartset could be lazy and therefore more flexible.
>
> (note: I know what smartset do, I kinda wrote them ;-) )
>
> In the case we are discussing (hidden computation, obsolete
> computation). We do not use any of the above property. Martin even had
> to work around some of the limitation with an extra `set` conversion.
>
> a quick check seems to indicate switching to set remove a 20% overhead
> for computing obsolescence and 45% for computing hidden (!). I'll send a
> small series to give these logic access to the set version soon™.

>From a high-level, this is an example where our vision differs.

smartset is in Python which could contribute to its slowness today. But it's
a powerful abstraction and a superset of what Python set can do.

In the future, everything could be efficiently lazy with some help from C.
The phase revset is lazy, the obsolete revset, all the troubles set.

Converting a smartset back to Python set is making backward progress.


If all current code paths use the full set (and don't care about order), I
think it makes sense to return a plain set. I'd accept a patch that changes
that. I realize it conflicts with your vision, but it sounds like a pretty
small patch, so I'm not concerned about the possible churn of taking such a
patch that you later back out when you make things lazier.


>
> Cheers,
>
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel at mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170603/eecec572/attachment.html>


More information about the Mercurial-devel mailing list