compile server design document

[Timothy J. Wood]

    Cool!

   Some comments:

-  s/becomes we may allow/because.../

- The proposal doesn't explicitly say anything about threads, but you
   could have each connection to the socket fork a thread.  Are you
   planning on having this be threaded or having dual processor
   machines just start two servers?  If you have two servers, the IDE
   should really record 'file affinity' to avoid eventually growing both
   servers to their maximum size.

- This design would let you get rid of all the PFE/PCH code for
   persisting compiler state, assuming you want to dedicate VM
   space to keeping a server alive.  But, do you think it would be
   worth the effort to keep the 'persist the compiler state' code
   around so that a server could be kick started.

   As an example, each IDE project might have its own
   persistent server database stored in the build directory with the
   .o files for that workspace.  Thus, if I go through 15 different
   IDE project while doing a large build, I might save some time.

   This disallows cross-project sharing but would mean that you
   could have a large number of projects 'active' w/o having a
   absolutely huge VM sucking server running.

   Basically, I'm just wondering if you have any data on this one
   way or the other.

- Caching... what are your ideas on long lived servers?  This is
   especially relevant if you don't have per- IDE project servers
   (since one server could get handed thousands of files and grow
   without bound)

- 'initially' and 'init' seem less than ideal for the naming scheme.
   More descriptive, shorter and more unique names are possible:
   'init'/'reset' or 'startup'/'perfile', for example

- The 'depends-on-set' functionality seems like it would be very
    useful in higher levels than the preprocessor (forgive me if it
    misunderstood it... :)  Consider the case:

	foo.h:

		... many other decls ...
		extern void foo(float x);
		... some more decls ...

	foo.c:
		void foo(float x) {...}

	bar.c:
		void bar(float x) { foo(x); }

   If each decl was a 'fragment' then changing the type of the argument
   to 'foo' would cause only foo.c and bar.c to be recompiled (instead of
   all the files that include foo.h).

-tim




On Wednesday, February 26, 2003, at 05:27  PM, Per Bothner wrote:

> As I've hinted, I have been working for Apple on a "compile server".
> The idea is that the compiler when in server mode will re-use trees
> from header files.  I've attached a semi-detailed design documnent.
> This is in texinfo format (so it can later be merged into gccint.text).
> To generate html do: makeinfo --html gcc-server.texi
>
> I'll submit a patch for the first prototype shortly, though note
> that this is far from clean enough to check in as is.  Before the
> actual server, there is some amount of work in terms of splitting
> up compiler initialization into two parts:  one-time initialization,
> and per-compilation initialization.  I hope people will work with
> me on this.
>
> We're quite exited about this approach.  We think it can lead
> to substantial compile-time speed-ups, and possibly other benefits.
> A preliminary benchmark suggested that re-using a large set of
> header files (the Apple Carbon framework) was over 3x as fast as
> normal processing.
> -- 
> 	--Per Bothner
> per@bothner.com   pbothner@apple.com  http://www.bothner.com/per/
> <gcc-server.texi>