[Mono-dev] Incremental C# compiler
monoman at gmail.com
Wed Jul 12 09:47:28 EDT 2006
Lexing and parsing normally are very fast and depend only on the size
of the code being parsed. Semantic analysis is normally the most time
consuming step as loading referenced assemblies and sifting around the
huge metadata to resolve symbols and types is really the meat of the
compiler, also, new "compiled" code is "appended" to this metadata/AST
what increases the complexity of resolving symbols over time. Emission
of code is done in memory first so it is fast. Saving to disk is slow
but depends on emitted code size.
For incremental compiling, caching the metadata, would make everything
very fast, as normally very little would be changed from one
compilation to the other. But gmcs would have to invalidate only part
of the metadata/AST, what it wasn't built for.
Hope it helps,
On 7/12/06, David Srbecky <dsrbecky at gmail.com> wrote:
> It seems that my whole Edit and Continue effort boils down just to one
> thing: Being able to recompile as quickly as possible.
> The idea is that gmcs would not be used as a command line tool but as a
> library. After compilation it would keep all usefully data in memory so
> it could use them during an incremental compilation. For example, I do
> not think that it is necessary do parse again file that have not changed.
> I actually do not know what takes so long on compilation. Can anyone
> give me a rough estimate on how long the compiling stages take please?
> - lexing, parsing, semantic analysis and such
> - emission of code to System.Reflection.Emit
> - Saving of the assembly on disk
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
Rafael "Monoman" Teixeira
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." George Bernard Shaw
More information about the Mono-devel-list