<?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: Obviously there&#8217;s something wrong with the way I&#8217;m profiling perl scripts</title>
	<atom:link href="http://blog.xcski.com/2005/06/19/obviously-theres-something-wrong-with-the-way-im-profiling-perl-scripts/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.xcski.com/2005/06/19/obviously-theres-something-wrong-with-the-way-im-profiling-perl-scripts</link>
	<description>Everything I used to bore people on newsgroups and mailing lists with, now in one inconvenient place.</description>
	<pubDate>Sat, 19 Jul 2008 17:42:57 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Paul Tomblin</title>
		<link>http://blog.xcski.com/2005/06/19/obviously-theres-something-wrong-with-the-way-im-profiling-perl-scripts#comment-1026</link>
		<dc:creator>Paul Tomblin</dc:creator>
		<pubDate>Sun, 26 Jun 2005 22:24:55 +0000</pubDate>
		<guid isPermaLink="false">http://xcski.com/blogs/pt/2005/06/19/obviously-theres-something-wrong-with-the-way-im-profiling-perl-scripts#comment-1026</guid>
		<description>Richard, I've thought about something like that, but I like the flexibility of the relational model.  For instance, I have a separate table for runway data, and another one for communications frequencies.

I'm currently looking at using BerkeleyDB to handle the intermediate storage of the array, instead of slurping it all into memory.</description>
		<content:encoded><![CDATA[<p>Richard, I&#8217;ve thought about something like that, but I like the flexibility of the relational model.  For instance, I have a separate table for runway data, and another one for communications frequencies.</p>
<p>I&#8217;m currently looking at using BerkeleyDB to handle the intermediate storage of the array, instead of slurping it all into memory.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Letts</title>
		<link>http://blog.xcski.com/2005/06/19/obviously-theres-something-wrong-with-the-way-im-profiling-perl-scripts#comment-1025</link>
		<dc:creator>Richard Letts</dc:creator>
		<pubDate>Sun, 26 Jun 2005 20:32:06 +0000</pubDate>
		<guid isPermaLink="false">http://xcski.com/blogs/pt/2005/06/19/obviously-theres-something-wrong-with-the-way-im-profiling-perl-scripts#comment-1025</guid>
		<description>I've been thinking about this problem. I'm not sure that Perl and/or SQL is the right choice for the problem you're trying to solve in a constrained memory environment. In C some 15,000 nodes would only require some 45K of storage (plus some overhead), at the expense of reading all records once, and selected records a second time on output. If you need records sorted then sort-on-insert would be efficient. Is there a way you could break the problem into two, and use Perl for the display/control, and use C (or java, or other language) for the data-retrieval?</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been thinking about this problem. I&#8217;m not sure that Perl and/or SQL is the right choice for the problem you&#8217;re trying to solve in a constrained memory environment. In C some 15,000 nodes would only require some 45K of storage (plus some overhead), at the expense of reading all records once, and selected records a second time on output. If you need records sorted then sort-on-insert would be efficient. Is there a way you could break the problem into two, and use Perl for the display/control, and use C (or java, or other language) for the data-retrieval?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
