Re: Speedy compilers

zalman@netcom.com (Zalman Stern)
18 Dec 1998 12:12:10 -0500

          From comp.compilers

Related articles
[7 earlier articles]
Re: Speedy compilers bernecky@acm.org (Robert Bernecky) (1998-11-24)
Re: Speedy compilers icedancer@ibm.net (1998-11-30)
Re: Speedy compilers janusz.szpilewski@alcatel.pl (Janusz Szpilewski) (1998-11-30)
Re: Speedy compilers amitp@theory.stanford.edu (Amit Patel) (1998-12-10)
Re: Speedy compilers mfinney@lynchburg.net (1998-12-13)
Re: Speedy compilers eclectictech@usa.net (1998-12-18)
Re: Speedy compilers zalman@netcom.com (1998-12-18)
Re: Speedy compilers Rudi.Ziegaus@bingo.baynet.de (1998-12-18)
Re: Speedy compilers Rudi.Ziegaus@bingo.baynet.de (1998-12-18)
Re: Speedy compilers jeff-news@jeff-jackson.com (Jeff Jackson) (1998-12-18)
Re: Speedy compilers albaugh@agames.com (1998-12-19)
Re: Speedy compilers terryg@uswest.net (1998-12-19)
Re: Speedy compilers genew@vip.net (1998-12-19)
[3 later articles]
| List of all articles for this month |

From: zalman@netcom.com (Zalman Stern)
Newsgroups: comp.compilers
Date: 18 Dec 1998 12:12:10 -0500
Organization: ICGNetcom
References: 98-11-047 98-11-086 98-11-089 98-11-115 98-12-015
Keywords: performance

Amit Patel (amitp@theory.stanford.edu) wrote:
[...IBM's Visual Age C++ fast fully incremental compilation...]


Has anyone looked at Microsoft's Visual C++ 6.0 edit and continue
technology? It is somewhat different than speedy compilation as it
aims to remove disruption in the debug cycle. (Often you have to tweak
the application being debugged to get it into a state where the bug
occurs. This can easily take longer than the recompile cycle.)


I started playing with it today and it appears to do something very
useful. As you are debugging, you can make edits and at some point
say "Apply code changes." This quickly compiles the deltas and applies
them to the *running* application. You do not have to shut down the
debugger which is a big win. You can of even change a line of code and
then back up the PC to reexecute it. When execution ends, and code
changes have been applied, the linker is run to bring the on disk app
up to date. I'm sure there are caveats and I haven't pushed on the
obvious cadidates for problems. (E.g. removing a function call while
it has an activation record outstanding on the stack.)


I'll have to see how it actually works on a large project, but if it
is robust it will give a noticeable productivity improvement. (That is
of course a large if. Noticeably buggy compilers and debug tools are
almost always more of a loss than any possible win.)


And yeah, I'm sure the Lisp contingent out there is sighing in amused
disbelief :-)


-Z-


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.