Sharing a negative result: This PR attempts to cache printed trees on disk rather than in memory.

However, on the test suite, we save less than 30MB of residual memory on PrintedTree instances.

Baseline: 111MB
This PR: 85MB

Seems like most of the memory usage goes into SourceMapFragment. I guess the learning is to attempt and optimize that.

/cc @sjrd

Huh, that's bold. :P

I'm not really surprised that SourceMapFragments are the biggest culprit. For every few bytes worth of characters in PrintedTree buffers, there an entire instance of FragmentElement.Segment:

It might be worth investigating a serialized form of Fragments, which would encode these instances as byte sequences inside a unique buffer per Fragment.

It might be worth investigating a serialized form of Fragments, which would encode these instances as byte sequences inside a unique buffer per Fragment.

Yeah, I'll take a stab at this.