On Mon, May 30, 2016 at 01:32:08PM +0200, Remi Galan Alfonso wrote:
> William Duclot <william.duclot@xxxxxxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html