On Thu, Jun 28, 2007 at 11:18:50PM -0700, Zack Weinberg wrote: > On 6/28/07, Nathaniel Smith <[EMAIL PROTECTED]> 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. _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
