|Incremental compilation. email@example.com (1994-11-23)|
|Re: Incremental compilation. firstname.lastname@example.org (1994-11-24)|
|Re: Incremental compilation. email@example.com (1994-11-28)|
|From:||firstname.lastname@example.org (Cliff Click)|
|Organization:||Hewlett Packard Labs, Cambridge Research Office|
|Date:||Mon, 28 Nov 1994 18:02:16 GMT|
email@example.com (Scott Hess) writes:
>Any good pointers towards books or articles which describe
>implementation of "incremental compilers"?
>Since I've probably just trampled on someone's definition ... the
>term as I am using it means that given a document D in the source
>language, there is some target representation for the document,
>D', which the compiler translates D into [C(D)=D']. "Incremental"
>comes into play when you want to apply a set of deltas (dD) to D.
>Assume that the deltas are much smaller than the document, and that
>the compilaion process is expensive in some manner, it can be
>helpful to find a means of converting dD into some dD', which is
>a delta for the target document D'. It may be that D'+dD' is less
>expensive to calculate than C(D+dD).
Well, here's an annoying argument. For optimistic analysis (e.g.,
conditional constant propagation, global congruence finding, etc),
your dD (change in source) can be small, and dD' (change in compiled
code) can be small BUT the computation of dD' from dD may require O(D) time.
You may have to check most of the source, and the time to do an incremental
update will be no better than compiling the whole procedure.
This is worst-case behavior. Average case can be a lot better.
And this doesn't apply if you avoid various kinds of global analyses
Return to the
Search the comp.compilers archives again.