[Monotone-devel] Re: Improving client side performance of pulls

[Graydon Hoare]

Eric Anderson wrote:

> I see a number of possible solutions:
>   1) write a custom string allocation system that runs without locks and 
>      modify all of the string stuff to use that.  Very ugly, but possibly
>      made easier by the use of the vocab wrappers.

See quick_alloc.hh. The idea was (once upon a time) to make the QA macro 
know how to be a fast, non-threadsafe allocator on every platform. 
Conceivably we could make the vocab stuff use that.

(sure would be nice if glibc / libstdc++ had some sort of interface for 
requesting non-locking behavior globally)

>   2) include a non-unicode version of boost-regex in monotone so that it 
>      can be built without threading support. Ugly duplication of code and
>      build bits, and doesn't fix the problem unless all the vendors ship
>      non-pthread versions of the other boost libraries.
>   3) write a fake shim library that emulates all of the pthread calls, but
>      does nothing and aborts if something tries to create a thread. This
>      just seems wrong as an approach, but is possibly the simplest to 
>      implement.

Personally, both these sound pretty awful. I think I'd prefer to think 
harder about alternatives. If there's a hot allocation path (look for a 
stack frame context) maybe we can use some sort of recycling allocator 
there or rearrange code at a higher level to be less painful.

> Does anyone have some other ideas?  All of these solutions seem bad.
> If there aren't other ideas, opinions on which is the "least-bad"?

Well, there's always room for such micro-optimizing, but only about half 
our big wins have come from such things; the other half have come from 
"stepping up a level" and attacking a bad data structure or algorithmic 
decision. I have a hunch that that's the right level to attack the 
pull-speed problem, though it's just a hunch.

For example, we've been recently discussing rearranging the roster 
storage format such that incoming revisions *don't* require building a 
fresh roster, serializing and xdelta'ing it. Instead, we might be able 
to get away with just holding a set of rosters in memory representing 
the graph frontier as we receive revs. Then we could edit such rosters 
"in place", capture the edits in a roster-describing form (including 
node IDs and markings), and insert those edits into the database. This 
might also help with the annotate-speed problem.

I've got a bit of code on this already; I'll post more for discussion 
when I get back from a vacation, in a couple weeks.

-graydon