Alternative compression algorithms for workers code

[laplab]

Hey! Is there any chance for Cloudflare Workers to support compression algorithms other than just gzip?

We provide a library for developers which has a Rust core compiled to WASM. Cloudflare Workers runtime compresses the WASM module using gzip from 3MB into roughly 1.2MB. Unfortunately, this is still too big for a library. Worker size limit on the free tier is only 1 MB, so we need (library size + user code size) to fit into that. Maximum size we have in mind for our library is 800KB.

We have exhausted all options of reducing the code size on our end (like dependency pruning, unused code elimination, wasm-opt, etc). The fact is that Rust just isn't optimized for code size.

As an alternative, we tried to experiment with different compression algorithms. We observed that LZMA and ZSTD(20) algorithms provide us with 770KB and 800KB WASM modules respectively, which is very promising. Unfortunately, CloudFlare Workers do not allow to run WASM code generated in runtime, so we cannot just unpack the WASM module in runtime ourselves and run it.

An ugly alternative to that is including a WASM runtime of our own (like wasm3) and running WASM inside WASM. We would like to avoid that, but this is the only option we have at the moment.

We believe that native support for algorithms like LZMA and ZSTD(20) would greatly help users coming from languages not optimized for code size, without the requirement for them to go into paid tier straightaway.

[elithrar]

cc @irvinebroque @kflansburg

[irvinebroque]

Hey @laplab, thanks for starting this discussion. Curious what the library is?

We'll take a look at what we can do here. You shouldn't have to include another Wasm runtime just to make things fit.

The size limit for all paid Workers is 10MB (formerly 5MB) and we'll keep evaluating how we can extend our limits here.

[sorenbs]

This is Prisma. We are very keen to make this fit for Cloudflare Workers users on the free tier.

[kentonv]

Using a different compression algorithm doesn't necessarily address the real problem for us, which is the code footprint after the module is loaded. Larger code footprints use more memory meaning we can have fewer isolates loaded at a time, in turn meaning we have to evict isolates more often incurring more cold starts. And larger code footprints also mean longer cold starts.

When it comes to Wasm, though, and libraries written in Wasm, there may be another way. V8 allows the same Wasm module to be loaded into multiple isolates without duplicating the code footprint. I wonder if the answer is to build a way that many free workers could share the same copy of Prisma in memory, in which case we could safely let the library be much larger.

Of course, this requires that many workers are running the same version of the library. There's a need to limit how many different versions appear in the wild. If we can count on new versions being API backwards-compatible, then we could potentially auto-update Workers so they are always on the same version, but this of course requires a lot of discipline on the part of the module developer to avoid accidental breakages.

We have started working on a framework for shared Wasm modules, but it is currently intended for modules provided by Cloudflare, which we can keep tight control over. Opening it up to third-party modules would add a lot of complexity, but could be really useful. This would be a big project though, and I'm not the one who makes the call on whether we're going to build something like this.

[laplab]

Thank you for sharing that, @kentonv! Great to know that there are potential ideas on the horizon. At the moment, we decided to continue our attempts to cut on the binary size from code organization/build system perspective.