Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Injected-Via-Gmane:	http://gmane.org/
To:	cygwin AT cygwin DOT com
From:	Rolf Campbell <rcampbell AT tropicnetworks DOT com>
Subject:	Sparse file performance (Was: Re: Sparse file criteria malfunction
	- binutils produces sparse .exe & .dll files)
Date:	Thu, 05 Jun 2003 20:19:46 -0400
Lines:	39
Message-ID:	<bbomij$ul5$1@main.gmane.org>
References:	<3EDF9E8D DOT AA452A2E AT ieee DOT org> <20030605201621 DOT GA19631 AT redhat DOT com>
Reply-To:	IDontLikePersonalReplies AT hotmail DOT com
Mime-Version:	1.0
X-Complaints-To:	usenet AT main DOT gmane DOT org
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507
X-Accept-Language:	en-us, en
In-Reply-To:	<20030605201621.GA19631@redhat.com>

Christopher Faylor wrote:
>>I remade the executables in an old version of inetutils.
>>The numbers below show that only the larger ones are sparse
>>(so the relative overhead is small) and that stripping them
>>removes sparseness. 
> 
> 
> This is exactly the kind of data I was looking for.  It seems to me that
> this suggests that there really is no issue that we have to worry about
> in this case.
> 
> Out of curiousity, does building the executable 1) without debugging options,
> and 2) with the -s option, also result in non-sparse files?
> 
> I'll test this myself when I get back to a windows computer but that won't
> be for some time.
> 
> I really appreciate your checking into this, Pierre.
> 
> cgf
I did some profiling of sparse-files vs. non-sparse files.  I found that 
accessing sparse files is between 5% and 10% slower (on 1.3.22/Win2000).

I created a 3Meg, 6Meg, 10Meg and 40Meg file using cp /dev/zero.  I then 
copied each file using windows explorer (and then verified that the 
sparse bit was gone).

Then I ran 'time cat filename > /dev/null'  (i ran it a few times to 
make sure the file was cached).  The performance difference was:

40Meg: 5%
10Meg: 7%
6Meg: 10%
3Meg:  5%

This wasn't the most sofisticated test ever, I did not ensure that the 
files were equally fragmented on disk.  But, it does show that sparse 
files are notably slower.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -