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

[Nathaniel Smith]

On Thu, Jun 28, 2007 at 11:18:50PM -0700, Zack Weinberg wrote:
> 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.

2.6.21 broke it, fixed in 2.6.21.5.  Dunno whether Debian has the
patch.

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

There is no way, ATM.

> >> 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 ;-)

Well, it's an annoying little thing -- the toposort we normally use
is, lexicographic sort by stored height.  One of the things
regenerate_caches needs to toposort for is, so it can calculate the
height entries in the correct order.  Chicken and egg.

> >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?

I dunno, you're the one looking at profiles :-).

-- Nathaniel

-- 
Electrons find their paths in subtle ways.