Re: Incremental compilation

ltd@netcom.netcom.com (Larry Drebes)
Fri, 24 Jan 92 04:06:54 GMT

          From comp.compilers
Related articles
Incremental compilation whatis@gnu.ai.mit.edu (1992-01-23)
Re: Incremental compilation preston@dawn.cs.rice.edu (1992-01-23)
Re: Incremental compilation wright@gefion.cs.rice.edu (1992-01-23)
Re: Incremental compilation ltd@netcom.netcom.com (1992-01-24)
Incremental Compilation shure@sd.co.il (Alexander Rozenman) (1999-11-02)
Re: Incremental Compilation xenophon@irtnog.org (Matthew Economou) (1999-11-03)
Re: Incremental Compilation maratb@CS.Berkeley.EDU (Marat Boshernitsan) (1999-11-05)
Re: Incremental Compilation bowdidge@apple.com (Robert Bowdidge) (1999-11-16)
Re: Incremental Compilation jsgray@acm.org.nospam (Jan Gray) (1999-11-25)
| List of all articles for this month |
Newsgroups: comp.compilers
From: ltd@netcom.netcom.com (Larry Drebes)
Keywords: parse
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: 92-01-081
Date: Fri, 24 Jan 92 04:06:54 GMT

>From article 92-01-081, by whatis@gnu.ai.mit.edu (Steve Boswell):
> [re keeping tokenized source around] ...
> I was wondering if the time it took to do the token-wise diff was longer
> than the time it would take to re-parse the entire file.


I am doing something similar, but storing a hash on the previous lexical
stream ( minus tokens designated for comments). What I really need to know
is the change in the content of a single routine, therefore the basic parse
is still needed. For me the parsing has never been a bottleneck, its the
steps that follow; which can be minimized to just the routine(s) that have
been modified.


larry-
--

Post a followup to this message

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