<?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: Fast File Loading</title>
	<atom:link href="http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/feed/" rel="self" type="application/rss+xml" />
	<link>http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/</link>
	<description>Code, 3D, Games, Linux and much more...</description>
	<lastBuildDate>Mon, 09 Nov 2009 03:12:38 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Daniel "NeoStrider" Monteiro</title>
		<link>http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/comment-page-1/#comment-171521</link>
		<dc:creator>Daniel "NeoStrider" Monteiro</dc:creator>
		<pubDate>Wed, 24 Jun 2009 01:18:53 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/#comment-171521</guid>
		<description>I would love to know about anyway to optimize file I/O over Linux.
I&#039;m having hard times on linux-powered smartphones, reading files from memory cards. What do you recomend me?</description>
		<content:encoded><![CDATA[<p>I would love to know about anyway to optimize file I/O over Linux.<br />
I&#8217;m having hard times on linux-powered smartphones, reading files from memory cards. What do you recomend me?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ent</title>
		<link>http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/comment-page-1/#comment-168589</link>
		<dc:creator>ent</dc:creator>
		<pubDate>Mon, 04 May 2009 20:34:12 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/#comment-168589</guid>
		<description>Big Muscle, did you try the benchmark in your machine? would like to know the results.</description>
		<content:encoded><![CDATA[<p>Big Muscle, did you try the benchmark in your machine? would like to know the results.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Big Muscle</title>
		<link>http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/comment-page-1/#comment-168569</link>
		<dc:creator>Big Muscle</dc:creator>
		<pubDate>Sat, 02 May 2009 18:55:14 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/#comment-168569</guid>
		<description>Hello. Nice article. I just don&#039;t understand how did you get similar performance for fread and ReadFile. I&#039;m working on a project where I need to read huge (a few GB) files and fread is about 6x slower than ReadFile, because it does other things as locking critical sections etc.</description>
		<content:encoded><![CDATA[<p>Hello. Nice article. I just don&#8217;t understand how did you get similar performance for fread and ReadFile. I&#8217;m working on a project where I need to read huge (a few GB) files and fread is about 6x slower than ReadFile, because it does other things as locking critical sections etc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cyan</title>
		<link>http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/comment-page-1/#comment-168548</link>
		<dc:creator>Cyan</dc:creator>
		<pubDate>Tue, 28 Apr 2009 13:46:11 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/#comment-168548</guid>
		<description>Hello

Yes, I just did it, thanks to your pretty clear explanation.

The first thing that striked me was that the timing necessary for completing the asynchronous call was exactly the same as for the synchronous call.

After looking a bit further into details, it appears that :
- My example focused on writing, rather than reading
- I&#039;m expanding the file size as it is written (well, quite common)
- Chunks are large (a few MB)
- In this case, the OS is single-deciding without notice to treat asynchronous calls as if they were synchronous.

So, actually, i cannot use the &quot;space&quot; for additionnal work.

I selected to test Writing first because it seems to be where most of the time is spent in my compression program. But maybe i should have a look at it again. Now, with 0.1s spent on a cached 100MB file, i wonder if there is really anything worthwhile to be saved...</description>
		<content:encoded><![CDATA[<p>Hello</p>
<p>Yes, I just did it, thanks to your pretty clear explanation.</p>
<p>The first thing that striked me was that the timing necessary for completing the asynchronous call was exactly the same as for the synchronous call.</p>
<p>After looking a bit further into details, it appears that :<br />
- My example focused on writing, rather than reading<br />
- I&#8217;m expanding the file size as it is written (well, quite common)<br />
- Chunks are large (a few MB)<br />
- In this case, the OS is single-deciding without notice to treat asynchronous calls as if they were synchronous.</p>
<p>So, actually, i cannot use the &#8220;space&#8221; for additionnal work.</p>
<p>I selected to test Writing first because it seems to be where most of the time is spent in my compression program. But maybe i should have a look at it again. Now, with 0.1s spent on a cached 100MB file, i wonder if there is really anything worthwhile to be saved&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ent</title>
		<link>http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/comment-page-1/#comment-168547</link>
		<dc:creator>ent</dc:creator>
		<pubDate>Tue, 28 Apr 2009 13:23:16 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/#comment-168547</guid>
		<description>Yes, more or less the same performance. What you get with the asynchronous methods is space for additional work that can be done in parallel.

Any way, you can download the benchmark and try it on your machine. I would appreciate any comments on that.</description>
		<content:encoded><![CDATA[<p>Yes, more or less the same performance. What you get with the asynchronous methods is space for additional work that can be done in parallel.</p>
<p>Any way, you can download the benchmark and try it on your machine. I would appreciate any comments on that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cyan</title>
		<link>http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/comment-page-1/#comment-168545</link>
		<dc:creator>Cyan</dc:creator>
		<pubDate>Mon, 27 Apr 2009 22:06:04 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/#comment-168545</guid>
		<description>Strange
your article benchmark seems to imply that
using Win32 API the &quot;standard&quot; way, with synchronous calls,
results in the same performance as the more complex asynchronous method.

Is that correct ?
W32	3.437	3.467	3.455	+44%
Async I/O	3.464	3.475	3.470	+44%</description>
		<content:encoded><![CDATA[<p>Strange<br />
your article benchmark seems to imply that<br />
using Win32 API the &#8220;standard&#8221; way, with synchronous calls,<br />
results in the same performance as the more complex asynchronous method.</p>
<p>Is that correct ?<br />
W32	3.437	3.467	3.455	+44%<br />
Async I/O	3.464	3.475	3.470	+44%</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ent</title>
		<link>http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/comment-page-1/#comment-167747</link>
		<dc:creator>ent</dc:creator>
		<pubDate>Mon, 09 Mar 2009 01:14:55 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/#comment-167747</guid>
		<description>Yes, I was expecting a better efficiency for the memory mapping. But I think in this kind of scenario (reading a big file in linear order) the results are normal.

I do not remember better results increasing the window size. But the test was done years ago. The source is provided with the article. May be you want to experiment and share with us the results.

I expect to write a revision of the article in a future.</description>
		<content:encoded><![CDATA[<p>Yes, I was expecting a better efficiency for the memory mapping. But I think in this kind of scenario (reading a big file in linear order) the results are normal.</p>
<p>I do not remember better results increasing the window size. But the test was done years ago. The source is provided with the article. May be you want to experiment and share with us the results.</p>
<p>I expect to write a revision of the article in a future.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon</title>
		<link>http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/comment-page-1/#comment-167744</link>
		<dc:creator>Jon</dc:creator>
		<pubDate>Mon, 09 Mar 2009 00:20:29 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/#comment-167744</guid>
		<description>I&#039;d expect memory mapping to be the fastest, as that&#039;s the only option that will get the file data into the process address space without any copying: the file cache is mapped directly in.

Your memory mapping test is adjusting the mapping using 128kb windows -  does the speed improve using larger windows? There isn&#039;t much reason not to use far larger windows, such as 64mb.</description>
		<content:encoded><![CDATA[<p>I&#8217;d expect memory mapping to be the fastest, as that&#8217;s the only option that will get the file data into the process address space without any copying: the file cache is mapped directly in.</p>
<p>Your memory mapping test is adjusting the mapping using 128kb windows &#8211;  does the speed improve using larger windows? There isn&#8217;t much reason not to use far larger windows, such as 64mb.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fast File Loading / part II - Load-In-Place &#124; EntBlog</title>
		<link>http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/comment-page-1/#comment-166090</link>
		<dc:creator>Fast File Loading / part II - Load-In-Place &#124; EntBlog</dc:creator>
		<pubDate>Sat, 27 Sep 2008 21:28:20 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/#comment-166090</guid>
		<description>[...] my first article on Fast File Loading, I described techniques directly related with the hardware and the Operating System to load files [...]</description>
		<content:encoded><![CDATA[<p>[...] my first article on Fast File Loading, I described techniques directly related with the hardware and the Operating System to load files [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James</title>
		<link>http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/comment-page-1/#comment-114678</link>
		<dc:creator>James</dc:creator>
		<pubDate>Wed, 30 Apr 2008 00:47:51 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/2006/10/25/reading-files-as-fas-as-possible/#comment-114678</guid>
		<description>My above post did not consider the compression case, since it is a different issue.</description>
		<content:encoded><![CDATA[<p>My above post did not consider the compression case, since it is a different issue.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
