[slime-devel] Re: recording and compiling changed definitions
quam at ai.sri.com
Tue Apr 10 04:18:12 UTC 2007
With the speed of modern processors, I have a hard time believing
that full recompilation of a few modified files is speed issue.
I have a Lisp application consisting of approximately 100K lines
(3.7MB) source code which can be completely recompiled in:
35 secs with Allegro Common Lisp 7.0
60 secs with CMUCL 19d
(AMD Athlon(tm) 64 X2 Dual Core Processor 4600+)
Typically when developing code, individual functions are incrementally
recompiled instantly, and the full recompilation is not needed.
Unless macro or struct definitions that are used by many files are
being changed frequently, there is rarely a need for full recompilation.
Helmut Eller wrote:
> That wouldn't work for me because I press C-x C-s and C-c C-c every
> few seconds anyway.
> > 2) work around projects where build times are 20 minutes or more. you
> > can only speed up the compiler so far, some projects are just big
> > and there's nothing you can do about it.
> That's what a incremental compiler is for: small changes to big
> programs can be compiled instantaneously.
> > now, having said all that there's no way, given an arbitrary set of
> > changed lisp forms and an arbitrary set of existing definitions in the
> > image, to properly infer what order they need to be compiled in
> > without compiling and executing them. this last step is going to error
> > if you get the order wrong, since you have to this to get the ordering
> > right you're screwed in the general case.
> That's true, but getting the order right on a per file basis instead
> on a per form basis doesn't sound very difficult. Most of the time,
> the order of the files is defined by some kind of Makefile/asdf
> definition. Instead of tracking forms in the editor, you could give
> the compiler an (ordered) list of files to watch. If one file changes
> the compiler could figure out which form changed and recompile only
> the necessary parts. (This would also allow proper error messages for
> those parts which haven't changed but are affected by the changes.)
> Writing such a compiler isn't easy, but adding those feature to the
> editor is IMO the wrong place.
More information about the slime-devel