Re: [PATCH 1/2] mem-pool: add mem_pool_strfmt()

> >> It would not allow the shortcut of using the vast pool as a scratch
> >> space to format the string with a single vsnprintf call in most cases.
> >> Or am I missing something?
> >
> > So here it sounds like you do care about some of the performance
> > aspects. So no, it would not allow that. You'd be using the vast pool of
> > heap memory provided by malloc(), and trusting that a call to malloc()
> > is not that expensive in practice. I don't know how true that is, or how
> > much it matters for this case.
> 
> In the specific use case we can look at three cases:
> 
> 1. xstrfmt() [before 1c56fc2084]
> 2. size calculation + pre-size + strbuf_addf() [1c56fc2084]
> 3. mem_pool_strfmt() [this patch]
> 
> The performance of 2 and 3 is basically the same, 1 was worse.
> 
> xstrfmt() and strbuf_addf() both wrap strbuf_vaddf(), which uses
> malloc() and vsnprintf().  My conclusion is that malloc() is fast
> enough, but running vsnprintf() twice is slow (first time to determine
> the allocation size, second time to actually build the string).  With a
> memory pool we almost always only need to call it once per string, and
> that's why I use it here.
> 
> The benefit of this patch (to me) is better code readability (no more
> manual pre-sizing) without sacrificing performance.
> 
> The ability to clear (or UNLEAK) all these strings in one go is just a
> bonus.