- 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 333: How can I ensure that my model is scalable?
Because eScript programs are assumed to be small, we did not put too much care into the optimization of the memory usage of our DOM. However, for languages in which programs tend to get much larger, such as C, Pascal, or C#, the definition of each individual field has to be carefully weighed. To represent <windows.h>, the number of DOM elements easily runs into hundreds of thousands or even millions.
When writing a model that needs to scale to large systems, you must pay careful attention to the memory your model uses. Traditional performance optimization techniques apply here, but lazy loading and most recently used (MRU) caching are particularly effective. The JDT’s Java model, for example, is populated lazily as the elements are accessed. Java element handles do not exist in memory at any one time for every Java project in your workspace. Most Java elements implement the Openable interface, indicating that they are lazily populated when you invoke methods on them that require access to underlying structures. Although all Openable elements can be explicitly closed when no longer needed, the model automatically closes the MRU elements by storing references to all open elements in a least recently used (LRU) cache. The abstraction layer of thin Java element handles allows expensive data structures to be flushed even if clients maintain references to those Java elements indefinitely. Abstract syntax trees are also generated lazily as they are needed and are quickly discarded when no longer referenced.
Although some of these performance enhancements can be added retroactively to your model implementation, it is important to think about scalability right from the start. Performance aspects of your model and of the tools built on top of it, need to be considered early in architectural planning. In particular, an architecture that does not let clients of your API maintain references to large internal data structures is essential to the scalability of your model.
Note
FAQ 334 Language integration phase 3: How do I edit programs?
FAQ 350 How do I create Java elements?