<?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: Snappy #38: Responsiveness Fixes Galore</title>
	<atom:link href="http://blog.mozilla.org/tglek/2012/09/04/snappy-38/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.mozilla.org/tglek/2012/09/04/snappy-38/</link>
	<description>Taras&#039; blog on Snappy, Startup, Telemetry and other Firefox peroformance matters</description>
	<lastBuildDate>Tue, 27 Nov 2012 16:50:13 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Andres</title>
		<link>http://blog.mozilla.org/tglek/2012/09/04/snappy-38/comment-page-1/#comment-35979</link>
		<dc:creator>Andres</dc:creator>
		<pubDate>Mon, 10 Sep 2012 21:58:07 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/tglek/?p=786#comment-35979</guid>
		<description><![CDATA[Hello, Dan Neely suggested I cross post a portion of a comment I wrote at the Memshrink blog.  Here is the relevant section of the original comment.


1. Observation: playing flash videos (e.g. Youtube, both directly and embedded in other pages) leads to higher memory usage. Several updates of the flash player didn’t fix this. FF becomes very slow when playing videos, videos skip, even the stream buffering of videos is slow, etc.

2. Observation: video playback is not as bad if I let the video download entirely first. Disk activity quiets down somewhat, and then performance is less bad. These led to:

3. Observation: video playback performance is worse when FF’s web data cache is full. It’s configured to the default, 1GB.

So this led to me to suspect  [that] FF is trying to clear up enough space in the data cache and it’s running into trouble.

From past experience with the data cache I know deleting it completely could require over 1 hour of disk i/o. In part this was because files would be deleted in random order (from the point of view of the file system). Eventually this was fixed so files were deleted in order plus deletion became some sort of offline process where the whole cache is first moved and then deleted in order, and this sped up managing the cache. However, it is still the case that the file cache tends to hold a huge number of mostly small files.

[While looking at the cached files, I had observed before many tiny files (~500 bytes) that were mostly the same by eye inspection, and I suspected perhaps they were wholly duplicate files.  The last time the cache filled up to capacity, I ran fdupes before deleting it.  fdupes produced output showing hundreds of duplicated files.]  So, question 1a: could it be possible to e.g. MD5 all files going into the file cache, and only add new files to the file cache when the MD5 hash is different (or, if the MD5 hash is equal, then a subsequent hash breaks the tie or the file contents are compared)?  The idea behind this is “no duplicate files in the cache” -&gt; “better cache utilization” -&gt; “less disk i/o” -&gt; “more responsive FF”.  Question 1b: when needing to make up enough space in the file cache, is it possible that the operation could result in time wasting when needing to free up (say) 30mb and the deletion proceeds by freeing ~500 bytes at a time?  If so, what could be done to address the problem?  I ask because, in general terms, heavy disk i/o might be confused with swap file thrashing and the implication that FF is using too much memory to begin with etc.



I’d be happy to spend some time to help figuring this stuff out.

Andres.]]></description>
		<content:encoded><![CDATA[<p>Hello, Dan Neely suggested I cross post a portion of a comment I wrote at the Memshrink blog.  Here is the relevant section of the original comment.</p>
<p>1. Observation: playing flash videos (e.g. Youtube, both directly and embedded in other pages) leads to higher memory usage. Several updates of the flash player didn’t fix this. FF becomes very slow when playing videos, videos skip, even the stream buffering of videos is slow, etc.</p>
<p>2. Observation: video playback is not as bad if I let the video download entirely first. Disk activity quiets down somewhat, and then performance is less bad. These led to:</p>
<p>3. Observation: video playback performance is worse when FF’s web data cache is full. It’s configured to the default, 1GB.</p>
<p>So this led to me to suspect  [that] FF is trying to clear up enough space in the data cache and it’s running into trouble.</p>
<p>From past experience with the data cache I know deleting it completely could require over 1 hour of disk i/o. In part this was because files would be deleted in random order (from the point of view of the file system). Eventually this was fixed so files were deleted in order plus deletion became some sort of offline process where the whole cache is first moved and then deleted in order, and this sped up managing the cache. However, it is still the case that the file cache tends to hold a huge number of mostly small files.</p>
<p>[While looking at the cached files, I had observed before many tiny files (~500 bytes) that were mostly the same by eye inspection, and I suspected perhaps they were wholly duplicate files.  The last time the cache filled up to capacity, I ran fdupes before deleting it.  fdupes produced output showing hundreds of duplicated files.]  So, question 1a: could it be possible to e.g. MD5 all files going into the file cache, and only add new files to the file cache when the MD5 hash is different (or, if the MD5 hash is equal, then a subsequent hash breaks the tie or the file contents are compared)?  The idea behind this is “no duplicate files in the cache” -&gt; “better cache utilization” -&gt; “less disk i/o” -&gt; “more responsive FF”.  Question 1b: when needing to make up enough space in the file cache, is it possible that the operation could result in time wasting when needing to free up (say) 30mb and the deletion proceeds by freeing ~500 bytes at a time?  If so, what could be done to address the problem?  I ask because, in general terms, heavy disk i/o might be confused with swap file thrashing and the implication that FF is using too much memory to begin with etc.</p>
<p>I’d be happy to spend some time to help figuring this stuff out.</p>
<p>Andres.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tglek</title>
		<link>http://blog.mozilla.org/tglek/2012/09/04/snappy-38/comment-page-1/#comment-35975</link>
		<dc:creator>tglek</dc:creator>
		<pubDate>Tue, 04 Sep 2012 20:58:57 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/tglek/?p=786#comment-35975</guid>
		<description><![CDATA[18]]></description>
		<content:encoded><![CDATA[<p>18</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ronald</title>
		<link>http://blog.mozilla.org/tglek/2012/09/04/snappy-38/comment-page-1/#comment-35973</link>
		<dc:creator>Ronald</dc:creator>
		<pubDate>Tue, 04 Sep 2012 20:36:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/tglek/?p=786#comment-35973</guid>
		<description><![CDATA[From the blog it is unclear to me which version of Firefox will have these fixes. Can you elaborate on that?]]></description>
		<content:encoded><![CDATA[<p>From the blog it is unclear to me which version of Firefox will have these fixes. Can you elaborate on that?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
