airtraffic control: Running a flight that uses Helm consumes half a gigabyte of ram

[Xe]

One of the things I've been looking at using Yoke for is to create a Heroku-ish platform for "mere mortal" VPSes (less than 4Gi ram) on top of Air Traffic Control. There's one small problem: A flight that invokes Helm (such as the one referenced in #88) makes Air Traffic Control consume over 512Mi of ram.

Is this something that's just endemic to Helm in WebAssembly or is there a bug here?

[davidmdm]

I do not believe this to be a bug outright.

A wasm program embedding helm generally takes 70+ MB of ram, and when compiled could be more.
512Mi seems like a lot of Ram but that may be Golang over-allocation or not eagerly running Garbage Collection.

Things that I will want to check:

• How much heap is allocated for a CompiledModule of a wasm program that embeds helm.
  • Is there any difference for different versions of wazero?

Also, it can be assumed that the ATC may generally use a lot of ram in order to cache the Compiled Modules in memory with their runtime, which allows in turn for the ATC to be incredibly responsive to new CRs.

However there's the possibility that this trade off is too steep.

Wazero also supports filesystem caching of modules, which in my experience adds an extra 100-200ms of compilation time per request.

This could be a better option for large wasm programs.

It may be possibly to configure this at the Airway Level ->

Proposed solution:

kind: Airway
metadata:
  name: example
spec:
  ModuleCache: 'memory' | 'filesystem'

It is however unclear if this is worth the extra complexity. Or if FS is just a better choice and should be the only choice. Or is having both options beneficial enough to justify them?

Thoughts and discussion very much welcome.