[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] some observations about roster node IDs
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] some observations about roster node IDs |
Date: |
Fri, 29 Jun 2007 00:49:56 -0700 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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.
- Re: [Monotone-devel] some observations about roster node IDs, (continued)