The Spoofax API offers a great amount of flexibility at runtime, including dynamic language discovery and dynamic language loading and re-loading. This comes at a price of runtime overhead for execution time, but also for runtime dependencies.

In contrast, generative compiler-compilers lack this flexibility but have less runtime overhead and typically come without runtime dependencies on other libraries. For some use cases, flexibility is not needed. The languages involved in a project and their artefacts are known beforehand, so the dynamic discovery and language loading features are actually not needed. Instead of searching for ESV files and then interpreting these ESV files to actually load the language, there could be generated code which loads these languages directly.

1. How big is the runtime overhead, both in execution time and in dependencies?
2. Which dependencies would remain in a less flexible Spoofax Core?

Submitted by Guido Wachsmuth on 28 June 2016 at 16:53

The overhead of dynamic loading in Spoofax itself is very low. Loading a language once takes virtually no time, although loading a parse table into JSGLR, and especially loading a Stratego runtime, poses a lot of overhead. There are no external libraries that make dynamic loading work, it’s all in Spoofax. You do have a dependency on the JSGLR parser and Stratego runtimes which are pretty significant though.

So if you could implement your own parser, analysis, and transformations outside of SDF and Stratego, and hook them into Spoofax (which is very hard and cumbersome right now), then you could save the speed and size overhead of the JSGLR and Stratego runtimes.

Thank you for the explanation, Gabriël. So there is no real benefit of getting rid of dynamic loading for some use cases, neither in runtime nor in dependency minimisation.

What causes the overhead in loading parse tables and Stratego runtimes? A master’s student will work on performance engineering for JSGLR starting in the Fall; we should take load times into account in that project.

Loading parse tables is pretty fast I think, but it does require the data from the parse table to be loaded into memory.

Loading a Stratego JAR has a much higher overhead. First of all, Stratego JARS can contain several megabytes of classes, and many classes, which Java has to load dynamically, which is slow. The stratego runtime also has to create a data structure for interoperating with the Stratego interpreter, which also takes some time and memory to set up.