<?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: 64k tinypy - garbage collection is tough</title>
	<atom:link href="http://www.philhassey.com/blog/2008/02/05/64k-tinypy-garbage-collection-is-tough/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.philhassey.com/blog/2008/02/05/64k-tinypy-garbage-collection-is-tough/</link>
	<description>games, tech, web, stuff, biz, and bilge</description>
	<pubDate>Wed, 27 Aug 2008 23:24:08 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Rene Dudfield</title>
		<link>http://www.philhassey.com/blog/2008/02/05/64k-tinypy-garbage-collection-is-tough/#comment-910</link>
		<dc:creator>Rene Dudfield</dc:creator>
		<pubDate>Tue, 05 Feb 2008 23:24:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.philhassey.com/blog/2008/02/05/64k-tinypy-garbage-collection-is-tough/#comment-910</guid>
		<description>Hi,

that's pretty cool :)  Only 40% reduction in speed is pretty good for replacing a big mature library like libgc.  I'm sure you can eventually make it faster, and getting rid of the libgc dependency is really good.

A couple of memory debuggering and profiling aids:
- valgrind &lt;a href="http://valgrind.org/" rel="nofollow"&gt;http://valgrind.org/&lt;/a&gt;
- dmalloc &lt;a href="http://dmalloc.com/" rel="nofollow"&gt;http://dmalloc.com/&lt;/a&gt;

A memory pool of sorts should help speed things up.  Figure out the sizes that get malloc'd often and create a pool for that stuff.  Like a small cache of objects you can draw from.

Also reducing many small mallocs into one is another optimization.  So instead of asking to create one object change your code to create many objects.

So if you do something like range(1000) it can do one malloc, and not 1000.  &lt;a href="http://rene.f0o.com/mywiki/BatchingApis" rel="nofollow"&gt;http://rene.f0o.com/mywiki/BatchingApis&lt;/a&gt;

I'm sure profiling (probably with valgrind) will help you speed it up too.


cu,</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>that&#8217;s pretty cool <img src='http://www.philhassey.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  Only 40% reduction in speed is pretty good for replacing a big mature library like libgc.  I&#8217;m sure you can eventually make it faster, and getting rid of the libgc dependency is really good.</p>
<p>A couple of memory debuggering and profiling aids:<br />
- valgrind <a href="http://valgrind.org/" rel="nofollow">http://valgrind.org/</a><br />
- dmalloc <a href="http://dmalloc.com/" rel="nofollow">http://dmalloc.com/</a></p>
<p>A memory pool of sorts should help speed things up.  Figure out the sizes that get malloc&#8217;d often and create a pool for that stuff.  Like a small cache of objects you can draw from.</p>
<p>Also reducing many small mallocs into one is another optimization.  So instead of asking to create one object change your code to create many objects.</p>
<p>So if you do something like range(1000) it can do one malloc, and not 1000.  <a href="http://rene.f0o.com/mywiki/BatchingApis" rel="nofollow">http://rene.f0o.com/mywiki/BatchingApis</a></p>
<p>I&#8217;m sure profiling (probably with valgrind) will help you speed it up too.</p>
<p>cu,</p>
]]></content:encoded>
	</item>
</channel>
</rss>
