Re: [Monotone-devel] net.venge.monotone.experiment.performance

[Nathaniel Smith]

On Sun, Aug 06, 2006 at 12:58:31AM -0700, Eric Anderson wrote:
> Nathaniel Smith writes:
>  > In the future, it would be convenient if you could commit different
>  > changes in parallel rather than sequence (possibly even as different
>  > branches), so that they could be merged individually; as it was, I had
>  > to use pluck and remove some extraneous changes, so you may have some
>  > extra work merging back to .performance.
> 
> So having a multi-headed branch is an interesting suggestion.  I
> thought about it initially and decided against for two reasons:
>   1) I'm trying to build an optimized version of monotone that I can
>      release internally that will go faster than the last version I 
>      optimized.

Nod.

>   2) When optimizing I find that once you optimize a few things, you
>      can get the time down enough that you can find something else 
>      that's taking up a lot of the time, but was hidden by noise 
>      caused by other parts of the system.  
> 
> As an example of (2), I've finally tracked down that a huge amount of
> time (~30%) is being spent during a pull writing out the rosters.  I
> was able to tell because I'd optimized enough that a run of callgrind
> was plausible (it still took 15 hours), and when I looked at the
> results I wasn't spending time looking at the other overhead that was
> easily identifyable with oprofile.

Hmm.  I _think_ you can probably do better than this with more
judicious use of tools.  For instance, it is easy to run callgrind on
a smaller work set, and you will still probably find that 30% of that
workset is spent doing the same thing as before.  You can also, for
instance, use kcachegrind to grok oprofile output.  (There is a script
in contrib/ that does this conversion.)

To make things even easier, I just went ahead and added oprofile and
callgrind instrumenters to mtn_benchmark :-).  So you can now say

  python2.4 benchmark.py -m mtn=../opt/mtn \
    -b pull='InitialPull(ExistingRepo("path/to/mtn.mtn"))' \
    -i oprofile='OprofileInstrumenter()' \
    scratch results --cache cache

and results/pull-mtn-oprofile/ will have an oprofile summary report,
oprofile callgraph reports separately for client and server, _and_
kcachegrind-compatible files for both client and server.

And for callgrind you can do:

  python2.4 benchmark.py -m mtn=../opt/mtn \
    -b pull='InitialPull(SimpleRandomRepo(num_files=50, num_revisions=100), 
wait_time=20)' \
    -i callgrind='CallgrindInstrumenter()' \
    scratch results --cache cache

and it'll generate a relatively small data set to run callgrind on.
(That one'll still take a while, but definitely less than 15 hours...)

Well, I _think_ it will work.  You broke SimpleRandomRepo pretty good
with your mkrandom changes :-).  I'm not sure if I fixed stuff up
right; I've been getting weird errors.

SimpleRandomRepo is maybe not the best pull benchmark either, seeing
as how it's entirely straight-line and with a relatively sucky model
of what changes (e.g., no hot-spot files like ChangeLog, which can
really matter), but hey...

> Conversely, your goal is to pick out the subset of fixes that I make
> that are good enough for mainline. I'll hope you'll also use the
> combination of all of them as a comparison point in benchmarking.
>
> One possibility I thought of to achieve both our goals would be to
> have a nvmep.merged and nvmep.individual; avoiding the problem of
> having 10-50 branches, but it turns out that propogate won't work with
> multiple heads.  I generally try to avoid lots of branches because it
> makes the output of mtn list branches and viewmtn much harder to read,
> especially since most of these branches would have 1 or maybe 2
> commits on them and then would be done, but I could go down that path
> if that's the best solution.

That probably is the best solution.  Anything else we come up to solve
the problem of working with a bunch of distinct changes, made in
parallel, with different purposes, that helps us keep track of which
is which... is just going to end up being isomorphic to branches
anyway.

We do definitely need better UI to them, though, that's a known
problem which we will fix at some point...

> I wonder though if this isn't an interesting use-case for monotone
> that would be worth supporting more directly, either by allowing a
> propogate from an unmerged branch, or by allowing the definition of a
> branch that is made up of merging a number of other revisions/branches
> in some order (similar to quilt as I understand it from skimming the
> documentation).  Thoughts?

You can achieve a propagate from an unmerged branch using
"explicit_merge" -- propagate is just lacking the syntax to specify
which head you want, there's no deep problem.  Something like

  mtn explicit_merge h:my-branch <name revision on unmerged branch> \
    my-branch

I'm not sure what the sematnics would be for a magic branch that
always reflects the result of merging whatever happens to exist right
now... that seems tricky to make really sensible.

-- Nathaniel

-- 
Eternity is very long, especially towards the end.
  -- Woody Allen