On Mon, Nov 27, 2017 at 05:48:14AM +0000, kshe wrote:
> On Mon, 27 Nov 2017 00:42:01 +0000, Theo de Raadt wrote:
> > This needs worst-case performance measurements.
>
> The only instances where performance could be a problem are in
> vfprintf.c and vfwprintf.c, where the calls happen inside a loop; but
> for these, in fact, the best solution would be to use recallocarray
> directly: rather than repeatedly freeing (and clearing) `convbuf' and
> reallocating a fresh one every time it is needed, it should be kept
> around and passed to __wcsconv() and __mbsconv(), along with some
> accounting of its current size, so that these functions could then call
> recallocarray appropriately. However, this optimisation would be more
> intrusive than the diff I submitted, and would therefore demand greater
> familiarity with stdio's source, which I have not yet acquired.
>
> That being said, in all other cases, since the way stdio functions fill
> their buffers is much more costly than simply writing a bunch of zeros
> in sequence (or merely calling munmap(2)), no real slowdown is to be
> expected. I should also point out that recallocarray is currently used
> inside several loops in fvwrite.c, fgetln.c and getdelim.c, but no one
> complained that the affected functions became too slow, because doing
> things, as stdio does, like reading from and writing to disk or decoding
> and converting user input will always dominate the effect of a few calls
> to discard temporary buffers.
>
> Regards,
>
> kshe
I was thinking: only point against your statement is that there could
be cases where a very large buffer is used, but only a small part of
it is used. In that case, clearing the buffer is more costly. Luckily,
in those cases malloc just calls munmap(2) without clearing.
Still, I would like to see benchmarks to validate assumptions.
-Otto
