On Tue, 28 Nov 2017 05:52:25 +, Theo de Raadt wrote:
> You could compare make build times. I suspect this will slightly
> exceed the noise floor.
Without the patch, my fastest laptop (amd64, 8-core i7 @ 3.4 GHz)
managed to
$ make obj && make -j8 build
in exactly 2359 seconds; with
On Tue, 28 Nov 2017 05:52:25 +, Theo de Raadt wrote:
> > In fact, can recallocarray be faster than plain free followed by calloc?
>
> Yes.
>
> I think you are missing some nuances. These added functions have fast paths
> and slow paths. freezero() isn't just a bzero, it also has munmap()
>
> In fact, can recallocarray be faster than plain free followed by calloc?
Yes.
I think you are missing some nuances. These added functions have fast paths
and slow paths. freezero() isn't just a bzero, it also has munmap()
sequences. You are adding forced bzero or munmap() in circumstances
On Mon, 27 Nov 2017 08:01:25 +, Otto Moerbeek wrote:
> On Mon, Nov 27, 2017 at 05:48:14AM +, kshe wrote:
> > On Mon, 27 Nov 2017 00:42:01 +, Theo de Raadt wrote:
> > > This needs worst-case performance measurements.
> >
> > The only instances where performance could be a problem are in
On Mon, Nov 27, 2017 at 05:48:14AM +, kshe wrote:
> On Mon, 27 Nov 2017 00:42:01 +, 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
On Mon, 27 Nov 2017 00:42:01 +, 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
This needs worst-case performance measurements.
On Sun, 26 Nov 2017 19:56:03 +, kshe wrote:
> Hi,
>
> Shortly after recallocarray(3) was introduced, it was put into use for
> several objects internal to the stdio library "to avoid leaving detritus
> in memory when resizing buffers". However, in the end, this memory is
> still released by
Hi,
Shortly after recallocarray(3) was introduced, it was put into use for
several objects internal to the stdio library "to avoid leaving detritus
in memory when resizing buffers". However, in the end, this memory is
still released by plain free(3) calls.
The same reason that motivated the
