Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Date:	Wed, 3 Jan 2001 17:35:15 +0300
From:	Egor Duda <deo AT logos-m DOT ru>
X-Mailer:	The Bat! (v1.45) Personal
Reply-To:	Egor Duda <cygwin AT sources DOT redhat DOT com>
Organization:	DEO
X-Priority:	3 (Normal)
Message-ID:	<4128499630.20010103173515@logos-m.ru>
To:	Dan Morris <dmorris AT tiqit DOT com>
CC:	cygwin AT sources DOT redhat DOT com
Subject:	Re: Cygwin fstat and NT caching
In-reply-To:	<Pine.GSO.4.21.0101030036510.14474-100000@fable6.Stanford.EDU>
References:	<Pine DOT GSO DOT 4 DOT 21 DOT 0101030036510 DOT 14474-100000 AT fable6 DOT Stanford DOT EDU>
Mime-Version:	1.0

Hi!

Wednesday, 03 January, 2001 Dan Morris dmorris AT tiqit DOT com wrote:

DM> Anyone know why this might be?  I looked through the du code; the only
DM> repeated filesystem access seems to be through stat() and lstat().  So I
DM> looked through stat() and lstat(), and I can't see any place where disk
DM> flushes are explicitly forced, or any place where Win32 calls are made with
DM> specific flags for ignoring the inode cache ... these seem to be the Win32
DM> filesystem calls that get made :

DM> GetVolumeInformation
DM> GetDriveType
DM> GetFileInformationByHandle
DM> GetFileSize
DM> GetFileType
DM> FindFirstFile
 
DM> I don't know why any of them would ignore the cache... any ideas?  I'm
DM> running Win2000, if that helps anyone...

They   don't   ignore   cache,   and   there's   no   disk   flushes.
GetFileInformationByHandle,  however,  requires opening file, which is
far     more    expensive    than    just    obtaining    it    via
FindFirstFile/FindNextFile.  moreover,  cygwin  tries to deduce if the
file  is  executable  by  file's header and this involves ReadFile. If
your  filesystem  contains  a  lot of symlinks, this makes things even
worse, because each symlink is resolved via ReadFile() too.

those   performance   tradeoffs   were  made  to  achieve  semantical
correctness of *stat calls.

If  you  want  to  improve  performance  of  du,  you should patch its
sources.  change  all calls to stat to bunch of native win32 api calls
needed to get statbuf fields used later. something like this:

  ...
#if defined (__CYGWIN__)
  ...
  statbuf.st_size = GetFileSize (file, &hwSize);
  ...
#else
  rc = stat (file, &statbuf)
#endif
  ...

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

- Raw text -