This is the mail archive of the
mailing list for the binutils project.
Re: libiberty: Don't needlessly clear xmemdup allocated memory
- From: Alan Modra <amodra at gmail dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, binutils at sourceware dot org
- Date: Mon, 30 May 2016 00:59:29 +0930
- Subject: Re: libiberty: Don't needlessly clear xmemdup allocated memory
- Authentication-results: sourceware.org; auth=none
- References: <20160528131223 dot GB18662 at bubble dot grove dot modra dot org> <xnk2id394s dot fsf at greed dot delorie dot com>
On Sat, May 28, 2016 at 10:12:19PM -0400, DJ Delorie wrote:
> Alan Modra <firstname.lastname@example.org> writes:
> > * xmemdup.c (xmemdup): Use xmalloc rather than xcalloc.
> In glibc at least, calloc can be faster than memset if the kernel is
> pre-zero-ing pages. Thus, in those cases, your change makes the code
> slower by adding an unneeded memset. Have you considered these cases?
Actually, I didn't consider that.. I was looking at usage of xmemdup
in binutils, gdb and gcc, and noticed that a lot of the calls don't
need to clear any memory, and those that do only need to clear at most
two bytes. ie. All uses have alloc_size <= copy_size + 2.
So in real-world usage of xmemdup, I think the possible gain of fresh
sbrk memory resulting in no internal calloc memset is minimal at best
and of course if calloc is reusing freed memory then it will
internally memset to zero.
Australia Development Lab, IBM