[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PCH Support
From: |
Helge Hess |
Subject: |
Re: PCH Support |
Date: |
Sat, 27 Aug 2005 15:43:35 +0200 |
On 26. Aug 2005, at 16:46 Uhr, Nicola Pero wrote:
... just wanted to encourage you and say that this would be a
fantastic
addition to gnustep-make! :-)
OK, the Linux/gcc4 issue isn't solved yet, but at least on OSX it
works (almost) like a charm.
I've added PCH to SOPE 4.5 and it now compiles in ~8mins instead of
~16mins on a PM G5, so it indeed gives a huge speed boost.
How to use
==========
First you need to reconfigure/reinstall gstep-make with --enable-pch:
./configure --enable-pch <your-options>
In your projects you create a header file which contains all the
files you usually want to include, in SOPE we already had such files
called "common.h", eg:
common.h:
#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
After that you need to tell gstep-make about that file by adding a
new variable:
MyProject_PCH_FILE = common.h
Thats it. 'make clean all' and it should compile much faster.
Notes
=====
- The common.h will be included in _every_ source file of the project
at the very top (automagically using -include). This is sometimes
confusing and can lead to bugs with non-PCH setups, but necessary to
ensure that the PCH actually gets used.
- On the first 'make all' the PCH will be generated. Subsequent
"touch *.m; make all" are marginally faster (for SOPE 4.5 with ~20
PCH's this is no measurable difference)
- The PCH will NOT pick up changes automagically. So you should not
add 'volatile' headers to the PCH or you might experience weird
effects (old headers getting used). Don't know whether auto-
dependencies help here, at least a .d file is generated.
- Do not use PCH if your project/subproject has just one or two
files. Will gain you nothin' but wasted diskspace.
- Precompiled headers are quite big! For SOPE common.h around ~13MB
each (~250MB for SOPE).
- I have the impression that PCH also increases Dual-CPU saturation
on the G5 (w/o using -j), don't know why. Maybe because cpp=>cc1obj
pipeline is multitasked and somehow better used.
- The newer Xcode's do something called shared PCH. Don't know how
this works, I suppose they hash the header-file and only regenerate
when they differ. Should save disk-space and some PCH generation time.
How to get it
=============
My gstep-make branch is available at:
http://svn.opengroupware.org/SOPE/trunk/gnustep-make
You can retrieve it as a patch to 1.11.0 using:
svn diff http://svn.opengroupware.org/SOPE/vendor/gnustep-make/
1.11.0 \
http://svn.opengroupware.org/SOPE/trunk/gnustep-make
Issues
======
I have one issue with subprojects, apparently they are run w/o a
submake invocation and somehow pick up wrong PCH_FILEs. Nicola, maybe
you can look into the changes and tell me what I did wrong? ;-)
Another minor issue the patch has is that the PCH must live in the
same directory like the makefile - when I use $(notdir), the PCH
compilation rule somehow doesn't get picked up (see comments in
makefile). I failed to see why (Nicola again ;-)
Note: to see this behaviour your main project and your subproject
need to use different PCH_FILE names (otherwise the subproject picks
the one of the parent).
PCH in Sarge gcc4 doesn't work. I won't have the time to run through
the full gcc bug-reporting procedure as outlined in:
http://gcc.gnu.org/bugs.html
If someone would find the time to build/submit a testcase it would be
excellent.
Greets,
Helge
PS: ratmice: I think you saw no speed gain because you didn't use -
include which you should to ensure that the PCH is actually used (the
PCH MUST be the first included header).
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org