Re: [PATCH 0/2] strbuf: improve API

From: Jeff King <peff@peff.net>
Date: Jun 1, 2016, 07:42 UTC
Message-ID: <20160601074218.GB14096@sigill.intra.peff.net>
In-Reply-To: <1069084553.156626.1464607928755.JavaMail.zimbra@ensimag.grenoble-inp.fr>

On Mon, May 30, 2016 at 01:32:08PM +0200, Remi Galan Alfonso wrote:

Show 16 quoted lines

> William Duclot <william.duclot@ensimag.grenoble-inp.fr> writes:
> > This patch series implements an improvment of the strbuf API, allowing
> > strbuf to use preallocated memory. This makes strbuf fit to be used
> > in performance-critical operations.
> > 
> > The first patch is simply a preparatory work, adding tests for
> > existing strbuf implementation.
> > Most of the work is made in the second patch: handle pre-allocated
> > memory, extend the API, document it and test it.
> 
> Seems interesting, however do you have any test/example that would
> show the difference of performance between using these optimizations
> and not using them?
> 
> Such values would make a nice addition to help convince people that
> your series is interesting to have and use.

I'll second the request for actual numbers. I'm a little dubious that malloc overhead is actually a significant place we are spending time, or if there is simply a superstitious avoidance of using strbufs. A huge number of strbufs are used for filenames, where we're about to make a syscall anyway. If your allocator for a 4K page is not competitive with a context switch, I suspect the best solution is to get a new allocator.

So I wonder if we have some less-invasive alternatives:

  1. Ship a faster allocator library with git, and use its malloc by
     default.

  2. Do caching tricks for strbufs used in tight loops. For example,
     have strbuf_release() throw its buffer into a last-used cache, and
     let the next strbuf_grow() use that cache entry. This cuts malloc()
     out of the loop.

     You'd probably want to protect the cache with a mutex, though. Most
     of git isn't thread-safe, but a few parts are, and strbufs are
     low-level enough that they might get called.

I have no idea if those ideas would work. But I wouldn't want to start looking into either of them without some idea of how much time we're actually spending on strbuf mallocs (or how much time we would spend if strbufs were used in some proposed sites).

-Peff