fix(compiler): improve JSII loading speed via binary format cache

[yoav-steinberg]

This PR caches the .jsii manifests in /tmp/.wing/jsii_manifest_cache/ in a binary format which is quicker to deserialize. It compares the original files to the cached ones using canonical path, file size and modification time. If no match is found it loads the original file and attempts to cache the file, if a match is found it'll load the JSII manifest from the cache.

In addition I identified some extra memory copying (cloning) of the imported JSII assemblies which was redundant. Eliminating this also added some performance.

A few notes:

1. I ended up using file metadata instead of the "fingerprint" field in the JSII manifest because doing so required unzipping gzipped .jsii files just to read the fingerprint field.
2. I didn't use bson or flexbuffer serde implementations because their performance is worse than plain serde_json(!!!). See: https://github.com/djkoloski/rust_serialization_benchmark.
3. I ended up using rmp_serde (msgpack serde). There are faster ones which we might move to in the future but the problem is that their implementation is incomplete. The main issue being lack of support for "self-describing" formats where the deserializer needs to figure out the output based on the schema information in the file itself (which is mainly required for deserializing rust algebraic enums and also handle missing fields in structs).
4. Even with rmp_serde I needed to remove the missing fields support from our serde definitions to get this working. rmp_serde actually does support missing fields but that hinders its performance (see rmp_serde::encode::write vs rmp_serde::encode::write_named).
5. I ended up using bincode, and specifically its non-serde serializer. I bincode as most fast serializer's doens't support the tag field for enum serialization which is required to deserialize .jsii files using serde_json. By using bincode's non-serde serializer we don't need to deal with the tag field. bincode seems like one of the faster serializers, we can consider some more options from here in the future.

update: I endded up using speedy which provided the best performance (see benchmarks)

benchmarks

normal test:
hyperfine -w 1 "cargo run --example compile -- testfile.w"
empty cache test (replace FORMAT with speedy/bincode/bson based on the name of the cache file generated):
hyperfine -w 1 -p "find ../.. | grep ".jsii.FORMAT" | xargs rm || true" "cargo run --example compile -- testfile.w"

test	rmp_serde no cache	rmp_serde cached	main branch	bincode no cache	bincode cached	speedy no cache	speedy cached
hello.w	136ms	106ms	105ms	134ms	100ms	111ms	99ms
bring_cdktf.w	10.4s	2.9s	4.1s	9.1	1.39s	4.1s	740ms
bring_awscdk.w	3.9s	1.2s	1.8s	3.42s	734ms	1.83s	416ms
bring_projen.w	263ms	141ms	161ms	260ms	118ms	189ms	111ms

profiling

Looking a the flamegraphs it's clear that deserializing the JSII manifests is still taking the bulk of the compilation time when importing large ones (cdktf...). I think there's value in continuing this work by either using a faster deserializer than rmp_serde bincode or dropping JSII deserialization and implementing our own type-system serde per namespace and caching that.

Checklist

• Title matches Winglang's style guide
• Description explains motivation and solution
• Tests added (always)
• Docs updated (only required for features)
• Added pr/e2e-full label if this feature requires end-to-end testing

By submitting this pull request, I confirm that my contribution is made under the terms of the Wing Cloud Contribution License.

[yoav-steinberg]

@MarkMcCulloh, @eladb Do you guys think I should add some env var setting to skip generating the cache for faster CI/testing?

[MarkMcCulloh]

Super nice perf numbers, looking forward to this change going in ❤️

[monadabot]

Congrats! 🚀 This was released in Wing 0.24.60.