delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/05/05/12:11:07

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
Message-ID: <004e01c31320$e7355860$0a00a8c0@nkelseyhome>
From: "Jafa" <jafa AT silicondust DOT com>
To: <cygwin AT cygwin DOT com>
Subject: Re: Compile time in Windows
Date: Mon, 5 May 2003 09:10:45 -0700
MIME-Version: 1.0
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" <jbaker AT qnx DOT com>
To: <jafa AT silicondust DOT com>
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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019