From mboxrd@z Thu Jan 1 00:00:00 1970 From: Egor Duda To: cygwin@cygwin.com Subject: Re: Optimizing away "ReadFile" calls when Make calls stat() Date: Wed, 14 Feb 2001 00:12:00 -0000 Message-id: <39319402546.20010214110838@logos-m.ru> References: <4.3.1.2.20010213134821.019a7130@pop.ma.ultranet.com> <20010213190131.14369.qmail@lizard.curl.com> <200102131935.OAA09136@envy.delorie.com> <20010213194612.17311.qmail@lizard.curl.com> <200102131954.OAA09284@envy.delorie.com> <20010213152313.A12830@redhat.com> X-SW-Source: 2001-02/msg00740.html Hi! Tuesday, 13 February, 2001 Christopher Faylor cgf@redhat.com wrote: CF> On Tue, Feb 13, 2001 at 02:54:01PM -0500, DJ Delorie wrote: >>> But it does nothing at all for the "usual case" I'm trying to >>> optimize, which is Make stat()ing a file but never reading it. >> >>It does, because stat() reads the file twice, once to see if it's a >>symlink, and once to see if the executable bit needs to be set. CF> If it is actually doing this, then that's a bug. I went to some effort CF> a year or so ago to do away with the second read. not meaning to be too pushy ;), but i'd like to bring the thread http://sources.redhat.com/ml/cygwin-developers/2000-03/msg00077.html back to life. I have to say, that not only ReadFile() is slowing things up, but CreateFile() too. i tend to think that cygwin- (or win32-) specific parts in ported applications are unavoidable evil (and "make" sources are already full of them). quick grep through "make" sources reveals that we need st_mode only to check in for S_ISREG(m) or S_ISDIR(m). So application porter can use this info to give stat a hint, and stat won't need to read file, and even open it. giving porter a single universal tool to be more specific about what he wants to get from stat() has one more benefit. otherwise, porter will tend to use different native win32 calls such as GetFileTime(), GetFileAttributes(), GetFileSize() etc. which are harder to find in large source tree when needed. with stat_lite he had just to do the simple grep. the only problem with this approach i can see is that if we introduce new API and applications start to use it we became "bound" to it and it'll be not too easy to deprecate ad remove it afterwards. OTOH, we can always make stat_lite() a simple wrapper to stat() if the latter become fast enough. i'm ready to submit an appropriate patch against current sources. Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple