- FAQ 319: What is eScript?
- FAQ 320: Language integration phase 1: How do I compile and build programs?
- FAQ 321: How do I load source files edited outside Eclipse?
- FAQ 322: How do I run an external builder on my source files?
- FAQ 323: How do I implement a compiler that runs inside Eclipse?
- FAQ 324: How do I react to changes in source files?
- FAQ 325: How do I implement an Eclipse builder?
- FAQ 326: Where are project build specifications stored?
- FAQ 327: How do I add a builder to a given project?
- FAQ 328: How do I implement an incremental project builder?
- FAQ 329: How do I handle setup problems for a given builder?
- FAQ 330: How do I make my compiler incremental?
- FAQ 331: Language integration phase 2: How do I implement a DOM?
- FAQ 332: How do I implement a DOM for my language?
- FAQ 333: How can I ensure that my model is scalable?
- FAQ 334: Language integration phase 3: How do I edit programs?
- FAQ 335: How do I write an editor for my own language?
- FAQ 336: How do I add Content Assist to my language editor?
- FAQ 337: How do I add hover support to my text editor?
- FAQ 338: How do I create problem markers for my compiler?
- FAQ 339: How do I implement Quick Fixes for my own language?
- FAQ 340: How do I support refactoring for my own language?
- FAQ 341: How do I create an Outline view for my own language editor?
- FAQ 342: Language integration phase 4: What are the finishing touches?
- FAQ 343: What wizards do I define for my own language?
- FAQ 344: When does my language need its own nature?
- FAQ 345: When does my language need its own perspective?
- FAQ 346: How do I add documentation and help for my own language?
- FAQ 347: How do I support source-level debugging for my own language?
FAQ 330: How do I make my compiler incremental?
The Eclipse Platform distinguishes between full and incremental builds. Incremental builds are much faster than a complete rebuild of a project because only the resources that have changed since the last build need to be considered for compilation.
Incremental builders are invoked each time a file is saved. To prevent a bad user experience, take special care to make the incremental builder as fast as possible. To make a compiler fast, it helps to understand that in most compilers little time is spent in compilation at all. Most time is spent resolving the context of the program, such as the build classpath.
In the case of eScript, two kinds of information need to be discovered from the target environment:
-
Starting with the Java classpath and the list of plug-ins referenced by a given script, the eScript compiler needs to find all possible external class types, as well as their methods and fields. This information is needed to determine whether a given input string refers to a class, an interface, a method, a field, or a local variable.
-
To facilitate the easy creation of the underlying Java class files for a given script, the eScript compiler, when it reads the contribution to a certain extension point, needs to interrogate the PDE to find out the class to extend or interface to implement.
The overhead of building the context is surprisingly constant for eScript and dwarfs the memory consumption needed for compiling a script. The scripts tend to be small, but the universe of plug-ins is large. The eScript compiler easily loads about 14,000 classes, simply to bind strings to type names. Rebuilding this contexts adds about three to four seconds to a compilation. The compilation of the script itself is less than a second, and is hardly noticeable.
By not discarding the context information after a compilation, performance of the next compilation run is greatly improved. The first compilation will be slow, but the next ones will be non-interruptive. However, note that optimization is always a time/space trade-off. The price we pay for faster compilation is about 15 MB of state that needs to be cached. JDT suffers from the same dilemma. Load a big Java project and close all perspectives, including the Java perspective, and the entire Java model with its thousands of classes is being held onto by the JDT.
Incremental builders that are run sporadically may be wise to run a timer and clean up their cache after a certain expiration time to free up heap memory used by the platform.
Note
FAQ 331 Language integration phase 2: How do I implement a DOM?