Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Jens Gustedt Newsgroups: comp.std.c Subject: Re: VLAs use less stack Date: Tue, 04 Sep 2012 10:28:56 +0200 Organization: A noiseless patient Spider Lines: 43 Message-ID: <5045BBC8.7040303@loria.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="2590e4fa64e7931a8f955de6703c052f"; logging-data="3453"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+NujeD9oG9YCByVMqbWlbwn/1N4xrTFR8=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 In-Reply-To: Cancel-Lock: sha1:H1qXJPwiq+2SUS8qSQo6n4DlpQM= Xref: csiph.com comp.std.c:1660 Am 04.09.2012 02:39, schrieb Joe keane: > In article , > Keith Thompson wrote: >> I was referring to *just* using malloc(), realloc(), and free(), >> even for small allocations, as opposed to falling back to malloc() >> for large buffers. > > So we are clear: > > a. fixed-size array only > b. variable-size array only > c. malloc and free only > d. fixed-size array with malloc and free backup > e. variable-size array with malloc and free backup > > Options 'a' and 'b' are easy: they don't work. > > Option 'c' is 'better', it works, except it may be slow. Generally > speaking i prefer code that is slow to code that doesn't work. > > Option 'd' is 'better'. > > But you shouldn't bother with it unless you have some reason to think > it's needed, either some evidence, or the fact that it has proven useful > in some other situation, such that it would be less time to code it that > way in the first place, rather than test it and find that it's a problem > and then fix it. > > I don't think that 'e' really buys you a lot versus 'd'. It really would depend on the use pattern. If the function is recursive and the average size of the allocation is small, say some value x, this could be worth doing. You could put the cut off at 10*x and the malloc case would appear "almost never", by still having a stack use of x on average, instead of 10*x. Then you could go deeper into recursion and maybe even more important the cache behavior could be a bit better. But I agree that these are a lot of hypothesis. Jens