Re: [Monotone-devel] some observations about roster node IDs

[Zack Weinberg]

On 6/28/07, Nathaniel Smith <address@hidden> wrote:
> Blah.  I assume you've also checked that you're not using one of the
> recent kernels that broke oprofile.

??? News to me.  I'm using whatever Debian's latest packaged amd64 kernel is.

Also, how the hell do you tell a client to use a Unix domain socket to
which you have attached a --stdio server?

> > Pull, checkout, large updates, merge were what I was thinking of.
> > unify_rosters, but I don't know what hits that.
>
> large pulls in the limit are the same as regenerate_rosters, modulo
> the stuff I mentioned about caches.

So if regenerate_rosters were fixed to use the heights toposort, it
would be a better approximation to pull?  That might be worth doing
just for that.  (also to only have one toposort ;-)

> unify_rosters is used by
> make_roster_for_merge_revision, which is mostly called by
> pull/regenerate_rosters (though also called once for all workspace
> operations in a merge workspace).  Update/merge/other workspace
> operations only have to touch one or two rosters, though, as opposed
> to 10,000, so they're generally much less sensitive to the speed of
> the roster code itself.  (Esp. for any workspace operation, workspace
> scanning is going to dominate any piddly hash-table lookups.)

So what's slow *besides* roster bashing?

zw