Re: compile server design document

["Timothy J. Wood" <tjw at omnigroup dot com>]

   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 at bothner dot com   pbothner at apple dot com  http://www.bothner.com/per/
> <gcc-server.texi>