Question on Linking

[cdietrich]

Hi, we are currently investigating memory consumption in a Langium-based CLI and noticed a significant cost in the default reference representation.

In DefaultLinker.buildReference / buildMultiReference, references are currently created as object literals with accessor properties:

langium/packages/langium/src/references/linker.ts

Line 219 in c28c0c4

const reference: DefaultReference = {

Because these getters (ref, error, $nodeDescription, and items for multi references) are created per reference instance, large workspaces with many references end up allocating a lot of closures/accessor-related storage.

In one of our larger workspaces we have about ~100k references. A heap snapshot showed the reference-related getter closures/accessor storage as a noticeable memory bucket. As an experiment, we replaced the object-literal references with class instances where the accessors live on the prototype, while preserving the existing lazy resolution semantics. This reduced our CLI max RSS from roughly 495 MB to 345 MB, and live heap after build from roughly 197 MB to 133 MB.

Is there a specific reason references are implemented as object literals rather than classes/prototype accessors? If not, would you be open to a PR that changes the default reference implementation to use class instances while keeping the public Reference / MultiReference interfaces unchanged?

[msujew]

@cdietrich We noticed that fairly recently as well. Having a class there would probably be much better 👍 PR would be appreciated

[cdietrich]

attempt #2159