Using Xtext for the first time is usually a very positive experience. Although Xtext is a complex generic framework, it is very easy to create your first Xtext-based editor, because of Xtext’s smart defaults and intuitive APIs. Even with minimal initial effort, the results are quite spectacular. Unfortunately the initial excitement often turns into disillusion as soon as you use your plugin on a big project.
Many development teams hit a performance wall as their plugin gets deployed and has to support larger projects. Internally, Xtext is a complex beast. The internals are carefully hidden from the user, but understanding them is critical to understand where the performance bottlenecks come from.
At Sigasi we have built commercial tool support for complex hardware description languages (VHDL, Verilog, SystemVerilog) using the Xtext framework. Our plugin needs to handle big industrial sized projects (>400k lines of code) that include large generated files (2 to 10 MB). To handle these kinds of projects we have developed a set of techniques over the last four years.
In this talk we will cover some performance critical pieces of the Xtext framework and evaluate what can be done to optimize it (think: parallel loading, caching, fast linking,…). We will also discuss some workarounds that can be used if nothing else works (light-weight editors, reducing the workload of the compiler).