<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Update: STL vs Gnulib Performance</title>
	<atom:link href="http://softwareramblings.com/2009/06/update-stl-vs-gnulib-performance.html/feed" rel="self" type="application/rss+xml" />
	<link>http://softwareramblings.com/2009/06/update-stl-vs-gnulib-performance.html</link>
	<description>Stephen Doyle&#039;s Ramblings on Software Engineering</description>
	<lastBuildDate>Thu, 22 Mar 2012 19:33:43 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Stephen Doyle</title>
		<link>http://softwareramblings.com/2009/06/update-stl-vs-gnulib-performance.html/comment-page-1#comment-59</link>
		<dc:creator>Stephen Doyle</dc:creator>
		<pubDate>Mon, 29 Jun 2009 20:26:07 +0000</pubDate>
		<guid isPermaLink="false">http://softwareramblings.com/?p=222#comment-59</guid>
		<description>yoco - compiler is gcc v4.0.1 and -O2 optimization</description>
		<content:encoded><![CDATA[<p>yoco &#8211; compiler is gcc v4.0.1 and -O2 optimization</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: yoco</title>
		<link>http://softwareramblings.com/2009/06/update-stl-vs-gnulib-performance.html/comment-page-1#comment-58</link>
		<dc:creator>yoco</dc:creator>
		<pubDate>Mon, 29 Jun 2009 19:19:41 +0000</pubDate>
		<guid isPermaLink="false">http://softwareramblings.com/?p=222#comment-58</guid>
		<description>What&#039;s your compiler and compile option? Debug version or optimized release version? The result is dramatically different.</description>
		<content:encoded><![CDATA[<p>What&#8217;s your compiler and compile option? Debug version or optimized release version? The result is dramatically different.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephen Doyle</title>
		<link>http://softwareramblings.com/2009/06/update-stl-vs-gnulib-performance.html/comment-page-1#comment-56</link>
		<dc:creator>Stephen Doyle</dc:creator>
		<pubDate>Sun, 28 Jun 2009 20:46:38 +0000</pubDate>
		<guid isPermaLink="false">http://softwareramblings.com/?p=222#comment-56</guid>
		<description>Hi ADL - See the reference to the previous post for details on methodology and source code. Insert is more correctly named push_back. Searching is using the stl::find algorithm for STL and its an unsorted search. A sorted search is another test.</description>
		<content:encoded><![CDATA[<p>Hi ADL &#8211; See the reference to the previous post for details on methodology and source code. Insert is more correctly named push_back. Searching is using the stl::find algorithm for STL and its an unsorted search. A sorted search is another test.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ADL</title>
		<link>http://softwareramblings.com/2009/06/update-stl-vs-gnulib-performance.html/comment-page-1#comment-55</link>
		<dc:creator>ADL</dc:creator>
		<pubDate>Sun, 28 Jun 2009 20:03:59 +0000</pubDate>
		<guid isPermaLink="false">http://softwareramblings.com/?p=222#comment-55</guid>
		<description>The numbers are still a little suspicious. &quot;insert&quot; is ambiguous; std::vector is optimized for push_back (append operations), std::deque is optimized for constant time push_back and push_front. If another container is able to do better than the STL implementation you&#039;re using, then it&#039;s a bug in your STL implementation.

The search chart is more troubling. How exactly are you searching? Both std::vector and std::deque have random access iterators, so you should be able to get log(n) search time - the best possible. std::list only has bi-directional iterators, so by definition it only offers O(n) search time. I suspect you have an unsorted container and are just doing std::find, which just does a linear walk. This is suboptimal, typically when searching a container is an important operation, you ensure the container is sorted and do binary searches.

I suspect the differences in your chart are due to the methodology you used, but since you haven&#039;t posted the source code I can&#039;t be of any help here. But generally:

* When inserting, you should be comparing std::vectors push_back to the equivalent in array_list
* When inserting, you should be comparing std::deque push_front to the equivalent 
* When searching, you should be using the member function search/find etc on the stl containers if present, otherwise use std::binary_search (to test t/f) or std::lower/upper_bound (to actually get the element). And the container, obviously, should be presorted.

It&#039;d also be helpful if you posted source code when you make such claims.</description>
		<content:encoded><![CDATA[<p>The numbers are still a little suspicious. &#8220;insert&#8221; is ambiguous; std::vector is optimized for push_back (append operations), std::deque is optimized for constant time push_back and push_front. If another container is able to do better than the STL implementation you&#8217;re using, then it&#8217;s a bug in your STL implementation.</p>
<p>The search chart is more troubling. How exactly are you searching? Both std::vector and std::deque have random access iterators, so you should be able to get log(n) search time &#8211; the best possible. std::list only has bi-directional iterators, so by definition it only offers O(n) search time. I suspect you have an unsorted container and are just doing std::find, which just does a linear walk. This is suboptimal, typically when searching a container is an important operation, you ensure the container is sorted and do binary searches.</p>
<p>I suspect the differences in your chart are due to the methodology you used, but since you haven&#8217;t posted the source code I can&#8217;t be of any help here. But generally:</p>
<p>* When inserting, you should be comparing std::vectors push_back to the equivalent in array_list<br />
* When inserting, you should be comparing std::deque push_front to the equivalent<br />
* When searching, you should be using the member function search/find etc on the stl containers if present, otherwise use std::binary_search (to test t/f) or std::lower/upper_bound (to actually get the element). And the container, obviously, should be presorted.</p>
<p>It&#8217;d also be helpful if you posted source code when you make such claims.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mad</title>
		<link>http://softwareramblings.com/2009/06/update-stl-vs-gnulib-performance.html/comment-page-1#comment-53</link>
		<dc:creator>Mad</dc:creator>
		<pubDate>Sun, 28 Jun 2009 10:47:22 +0000</pubDate>
		<guid isPermaLink="false">http://softwareramblings.com/?p=222#comment-53</guid>
		<description>Hi, 

I&#039;m having a hard time getting around those graphs. What does the insert graph mean ? I can&#039;t really imagine that inserting one element into a list ( not at the end or beginning but somewhere in the middle ) should be that much slower than doing the same op on a vector. 

Greets,
Mad

P.S.: Now that I read the previous post, I guess having named the &quot;insert&quot; graph &quot;push_back&quot; graph would quickly resolve those questions :)</description>
		<content:encoded><![CDATA[<p>Hi, </p>
<p>I&#8217;m having a hard time getting around those graphs. What does the insert graph mean ? I can&#8217;t really imagine that inserting one element into a list ( not at the end or beginning but somewhere in the middle ) should be that much slower than doing the same op on a vector. </p>
<p>Greets,<br />
Mad</p>
<p>P.S.: Now that I read the previous post, I guess having named the &#8220;insert&#8221; graph &#8220;push_back&#8221; graph would quickly resolve those questions <img src='http://softwareramblings.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Jansson</title>
		<link>http://softwareramblings.com/2009/06/update-stl-vs-gnulib-performance.html/comment-page-1#comment-52</link>
		<dc:creator>Peter Jansson</dc:creator>
		<pubDate>Sun, 28 Jun 2009 08:47:37 +0000</pubDate>
		<guid isPermaLink="false">http://softwareramblings.com/?p=222#comment-52</guid>
		<description>Nice work.

It would be interesting to see what the cause for the speed difference is, i.e. to compare the implementations.</description>
		<content:encoded><![CDATA[<p>Nice work.</p>
<p>It would be interesting to see what the cause for the speed difference is, i.e. to compare the implementations.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

