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 onPrintedTree instances.

Baseline: 111MB
This PR: 85MB

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

/cc@sjrd

Huh, that's bold. :P

I'm not really surprised thatSourceMapFragments are the biggest culprit. For every few bytes worth of characters inPrintedTree buffers, there an entireinstance ofFragmentElement.Segment:

It might be worth investigating a serialized form ofFragments, which would encode these instances as byte sequences inside a unique buffer perFragment.

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.