<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: C: Power of 2 Array Sizes</title>
	<atom:link href="http://thesmithfam.org/blog/2005/09/18/power-of-2-array-sizes/feed/" rel="self" type="application/rss+xml" />
	<link>http://thesmithfam.org/blog/2005/09/18/power-of-2-array-sizes/</link>
	<description>Your blog is probably better than mine.</description>
	<pubDate>Wed, 19 Nov 2008 04:59:07 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Michael J M Thomson</title>
		<link>http://thesmithfam.org/blog/2005/09/18/power-of-2-array-sizes/#comment-6651</link>
		<dc:creator>Michael J M Thomson</dc:creator>
		<pubDate>Sat, 17 Feb 2007 19:20:41 +0000</pubDate>
		<guid isPermaLink="false">http://thesmithfam.org/blog/?p=5#comment-6651</guid>
		<description>I'm sorry to say, but you're on the wrong track. The chief reason to request sizes from malloc() that are powers of two, is to reduce fragmentation in the way malloc() and free() etc. manage the heap. It has to do with the fact that often when you request memory areas with malloc() and then later free() them, instead of these functions getting the OS every single time to adjust how much heap is available (which would be incredibly expensive), free() will often instead make a note of the freed area in a list, the "free list", that malloc() can then exploit when fulfilling later requests. malloc() searches that list for an unused area of the heap that is at least the size requested, and if it finds one and it is larger than requested, the size of the excess area will get put back in the list. Now, with all that in mind, it should make sense that the free list is much more useful when the sizes are _evenly_divisible_ by virtue of them being powers of two. E.g. a call to free(32) followed by two calls to malloc(16) will perform better than if the former was a call to free(30), or if the latter were two calls to malloc(20).

Also worth pointing out, increasing e.g. a string's capacity by multiplying by 2 each time (and starting with a power of 2 of course), always means far less calls to realloc() than if you were to increase it linearly.

As for arrays, provided they're on the stack, make them the size you actually need. There's no performance gain to be had, the stack size will be increased once when the array comes into scope and decreased once when it leaves, regardless. I don't think indexing them is really an issue, as you say compilers will optimize things whereever possible, and I doubt modern processors have much more trouble with integer multiplication (generally a shift followed by zero or more adds) than with integer shift.

HTH. If not, try http://en.wikipedia.org/wiki/Dynamic_memory_allocation and the links from there, or google for Sun or IBM docs on the subject (I knew of at least one but can't find it offhand).</description>
		<content:encoded><![CDATA[<p>I&#8217;m sorry to say, but you&#8217;re on the wrong track. The chief reason to request sizes from malloc() that are powers of two, is to reduce fragmentation in the way malloc() and free() etc. manage the heap. It has to do with the fact that often when you request memory areas with malloc() and then later free() them, instead of these functions getting the OS every single time to adjust how much heap is available (which would be incredibly expensive), free() will often instead make a note of the freed area in a list, the &#8220;free list&#8221;, that malloc() can then exploit when fulfilling later requests. malloc() searches that list for an unused area of the heap that is at least the size requested, and if it finds one and it is larger than requested, the size of the excess area will get put back in the list. Now, with all that in mind, it should make sense that the free list is much more useful when the sizes are _evenly_divisible_ by virtue of them being powers of two. E.g. a call to free(32) followed by two calls to malloc(16) will perform better than if the former was a call to free(30), or if the latter were two calls to malloc(20).</p>
<p>Also worth pointing out, increasing e.g. a string&#8217;s capacity by multiplying by 2 each time (and starting with a power of 2 of course), always means far less calls to realloc() than if you were to increase it linearly.</p>
<p>As for arrays, provided they&#8217;re on the stack, make them the size you actually need. There&#8217;s no performance gain to be had, the stack size will be increased once when the array comes into scope and decreased once when it leaves, regardless. I don&#8217;t think indexing them is really an issue, as you say compilers will optimize things whereever possible, and I doubt modern processors have much more trouble with integer multiplication (generally a shift followed by zero or more adds) than with integer shift.</p>
<p>HTH. If not, try <a href="http://en.wikipedia.org/wiki/Dynamic_memory_allocation" rel="nofollow">http://en.wikipedia.org/wiki/Dynamic_memory_allocation</a> and the links from there, or google for Sun or IBM docs on the subject (I knew of at least one but can&#8217;t find it offhand).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
