Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <004e01c31320$e7355860$0a00a8c0@nkelseyhome> From: "Jafa" To: Subject: Re: Compile time in Windows Date: Mon, 5 May 2003 09:10:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Note-from-DJ: This may be spam Hi Jeff, Windows/Cygwin is quite a bit slower but I found one good trick... We had around 20 include directories in our structure (with absolute paths, not sure if that makes any difference). Each include directory has a master include which includes the local files. I wrote a program that went into each include directory, opened the master include for that directory, and every time it found a #include directive that it could resolve from within that local directory it inlined it into the output file. The 20 output files were stored into the output directory (build/include in our case) and that sub directory was placed first in the search list. Build times drop from over 9 minutes to about 3 minutes (PIII-800, Win2000). On a linux machine (PIV-2400) build times went from 30s to somewhere around 29 to 33s... probably just load noise. Becasue it kept the #inlucde directives it couldn't resolve in the local directory it didn't include anything twice (we only include master include files) and it ment if there was an include in a weird place then gcc would still be able to find it using the full search. The program also generated the dependancy files for make. This program started off as proof of concept to see if the include search and file opening had anything to do with the problem. Now that it has shown that this is a problem the solution would be to go back to cygwin and determin if cygwin is doing something stupid or its just Windows. Maybe we need to add some serious path caching, search caching, and file caching to cygwin so it isn't relying on windows file handling so much. I might have a play with some profiling code over the weekend. Nick Nick Kelsey Senior Software Engineer Ubicom www.ubicom.com ----- Original Message ----- From: "Jeff Baker" To: Sent: Monday, May 05, 2003 8:37 AM Subject: Compile time in Windows *This message was transferred with a trial version of CommuniGate(tm) Pro* I know this question is somewhat vague, but that's how it was presented to me so that's what I have to start with. I've been asked to find a way to make gcc and the binutils faster in Windows ( Cygwin ). Before I get down to the level of profiling the code I thought I'd ask if there are any compile time options I may not be aware of that might speed the works up a little. -- 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/