Re: [PATCH] use strbuf_add_unique_abbrev() for adding short hashes, part 3

From: Jeff King <peff@peff.net>
Date: Oct 10, 2016, 20:52 UTC
Message-ID: <20161010205243.fejhhvoos5tmqggh@sigill.intra.peff.net>
In-Reply-To: <af55f6d7-e1b1-272b-4fbe-a6eb2422b3be@web.de>

On Mon, Oct 10, 2016 at 10:46:21PM +0200, René Scharfe wrote:

Show 22 quoted lines

> Good question.  ALLOC_GROW() doesn't double exactly, but indeed the
> number of reallocations depends on the size of the added pieces.  I
> always thought of strbuf_addf() as an expensive function for
> convenience, but never timed it.
> 
> Numbers vary a bit, but here's what I get for the crude test program
> at the end:
> 
> $ time t/helper/test-strbuf strbuf_addf 123 123456789012345678901234567890
> 123123456789012345678901234567890
> 
> real    0m0.168s
> user    0m0.164s
> sys     0m0.000s
> $ time t/helper/test-strbuf strbuf_addstr 123 123456789012345678901234567890
> 123123456789012345678901234567890
> 
> real    0m0.141s
> user    0m0.140s
> sys     0m0.000s
> 
> Just a data-point, but it confirms my bias, so I stop here. :)

Heh. I'm surprised it's that big a difference, as processing simple printf strings should be pretty quick. I guess what happens in your program is that your strings almost always require a re-allocation (because you've just released, and we start small), and we literally end up doing a partial copy via vsnprintf(), realizing we're out of space, reallocating, and then running it again.

So it's noticeably worse when we _do_ reallocate, but usually that should be amortized across many calls (and if it isn't, then you are paying the much bigger price of lots of mallocs, and you should optimize that first :) ).

That being said, it doesn't seem like it would be _worse_ to move from addf to multiple addstrs.

-Peff