Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <005d01c0965e$b858bf50$0200a8c0@lifelesswks> From: "Robert Collins" To: References: <4 DOT 3 DOT 1 DOT 2 DOT 20010213134821 DOT 019a7130 AT pop DOT ma DOT ultranet DOT com> <20010213190131 DOT 14369 DOT qmail AT lizard DOT curl DOT com> <200102131935 DOT OAA09136 AT envy DOT delorie DOT com> <20010213194612 DOT 17311 DOT qmail AT lizard DOT curl DOT com> <200102131954 DOT OAA09284 AT envy DOT delorie DOT com> <20010213152313 DOT A12830 AT redhat DOT com> <39319402546 DOT 20010214110838 AT logos-m DOT ru> Subject: Re: Optimizing away "ReadFile" calls when Make calls stat() Date: Wed, 14 Feb 2001 19:18:25 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 14 Feb 2001 08:11:46.0629 (UTC) FILETIME=[C61D0750:01C0965D] ----- Original Message ----- From: "Egor Duda" To: Sent: Wednesday, February 14, 2001 7:08 PM Subject: Re: Optimizing away "ReadFile" calls when Make calls stat() > Hi! > 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). > > 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. > Perhaps a macro for each hint, that porters who have read up on cygwin can use? Rather than change the cygwin API, have a macro that calls GetFileTime() etc as appropriate... that way cygwin itself is not altered or tied to anything ? Rob -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple