[Monotone-devel] Improving client side performance of pulls

[Eric Anderson]

I've been looking into the cpu usage of pulls on the client.  Below is
the oprofile sampling from doing a pull of the monotone database,
measuring only the client.  Note that to actually get useful data on
where time is spent not in the monotone code itself, I found I had to
statically link to get the symbols for decoding.

412229    7.8868  __pthread_alt_unlock
364334    6.9705  __pthread_alt_lock
333146    6.3738  memset
311655    5.9626  std::string::_Rep::_M_grab(std::allocator<char> const&, 
std::allocator<char> const&)
311001    5.9501  sha1_block_data_order
209754    4.0131  memcpy
191024    3.6547  compute_delta_insns(std::string const&, std::string const&, 
std::vector<insn, std::allocator<insn> >&)
164996    3.1567  std::__default_alloc_template<true, 0>::allocate(unsigned int)

I was surprised there was so much time spent in lock and unlock, and
by sampling some back traces in gdb, I found it seemed to be all
memory allocation.  It took me a while to track down why monotone was
getting linked with libpthread.  On a debian Sarge (3.1) system, it's
because only multi-threaded versions of the boost libraries are
built. On etch (testing), non-multi-threaded versions of the libraries
are available, but libboost-regex still links with libpthread because
it links with libicu (to get i18n and unicode support), which links
with libpthread.

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

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