This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: alloca vs malloc
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Jeff Law <law at redhat dot com>, Rich Felker <dalias at libc dot org>, Florian Weimer <fweimer at redhat dot com>, Will Newton <will dot newton at linaro dot org>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 19 May 2014 11:15:25 +0200
- Subject: Re: alloca vs malloc
- Authentication-results: sourceware.org; auth=none
- References: <53760025 dot 10204 at redhat dot com> <CANu=DmhF=PZBVHtOPw5ZMCHjcy6vqdCvrRvY+xO9hzfkjTCRQA at mail dot gmail dot com> <53760826 dot 6090203 at redhat dot com> <20140516135304 dot GA29829 at domone dot podge> <20140516190504 dot GF507 at brightrain dot aerifal dot cx> <20140516203140 dot GA16889 at domone dot podge> <53768528 dot 1020502 at redhat dot com> <20140516232039 dot GA18631 at domone dot podge> <Pine dot LNX dot 4 dot 64 dot 1405162355230 dot 24114 at digraph dot polyomino dot org dot uk> <20140519042831 dot GD13048 at spoyarek dot pnq dot redhat dot com>
On Mon, May 19, 2014 at 09:58:31AM +0530, Siddhesh Poyarekar wrote:
> On Sat, May 17, 2014 at 12:07:54AM +0000, Joseph S. Myers wrote:
> > On Sat, 17 May 2014, Ondrej Bilka wrote:
> >
> > > For libc there are better alternatives, I will add priority to malloca
> > > cleanup. As glibc code is now alloca are mostly
> > > trivial or following this pattern occuring about hundred times:
> >
> > I suggest doing such cleanup in a maximally conservative and incremental
> > way:
>
> One straightforward set of changes in this area would be to replace
> the alloca+extend_alloca usage in getaddrinfo code with straight
> malloc+free. I doubt if the performance improvement due to using
> alloca is in any way noticeable in those functions given that the
> major costs there would be file or network I/O.
>
I will replace it everywhere. It does not improve performance for simple
reason that it is called after function returned insufficient space then
even if first buffer was 4096 bytes and its speed was cycle per byte you
already spent 4096 cycles.