Minimize impact on performance

[sam-goodwin]

SWC currently emits array literals for s-expressions which seems to be impacting performance, especially when enabling the transformer on node_modules.

To fix, there are various avenues to explore:

1. Emit a string instead of array literal - lexing and parsing javascript is much more expensive than parsing a JSON string. We can embed the data as a string and then parse it out at runtime using JSON.parse. This is a common technique deployed by bundlers to optimize embedded literal data.
2. Same as (1) except using something more optimal than JSON, e.g. flat buffers
3. Only emit references to free variables and then parse the function.toString() - we could even use SWC's JS bindings to do the parsing. This seems to be the most compact form.

[sam-goodwin]

I did some research into serialization formats and I came to the conclusion that our best option is likely MessagePack. I also considered BSON, ProtoBuf, FlatBuffers and pure JSON.

Reasons for MessagePack:

1. by far the fastest serialization format I could find
2. doesn't require a schema - unlike ProtoBuf or FlatBuffers, MessagePack doesn't require a schema which is perfect for our s-expression encoding.
3. faster and more compact than BSON

Most obvious question is why not JSON? IMO, JSON is unacceptable because we store a lot of numbers for the Span. Encoding numbers as text is highly inefficient as it take 1 byte per character.

The challenge with moving to byte encoding is that I don't know how to represent undefined.

[thantos]

The challenge with moving to byte encoding is that I don't know how to represent undefined.

0 or 255 (max byte)

[sam-goodwin]

It will have to be compatible with message pack encoding