WASM compilation in browser is both cool and unexpected. Seeing that the translation is quite direct, I do wonder how much optimization (either within the compiler or adding wasm-opt) will help and cost.
Great questions! There are a number of different performance tradeoffs to balance here:
1. Rendering performance (how efficient is rendering)
2. Startup speed (how large is our compiler)
3. Preset transition speed (if our compiler is slow, we might drop frames when switching between presets)
I would love to explore compiler optimizations (after all, this project was motivated by an interest in learning about compilers!) but I don't think it's the right thing to pursue yet. Moving Eel evaluation into Wasm was such a large win, that the actual Eel evaluation (the part which we could optimize in our compiler) is now a very very tiny slice of rendering. Most of the remaining time is still spent in WebGL and JavaScript.
Adding optimization passes would slightly increase our bundle size leading to slower startup. If the bundle size increase is minimal, that's probably fine, but trying to pull `wasm-opt` into the browser would probably be a significant increase.
Finally, as you watch the visualizer, it transitions from preset to preset every several seconds. This means that we are running the compiler at the same time as rendering. If optimization passes significantly increase cost of compilation, compiling could cause us to drop frames.
We could avoid this risk by trying to chop compilation up into smaller async tasks, or moving compilation to a web-worker, but that would involve adding some extra complexity to the system.
In summary, if we can speed up the other aspects of rendering to the point where executing the compiled Wasm is the bottleneck optimizations would be an interesting next step, but we would have to weigh them against the potential costs of slower startup and slower compilation.
3 comments
[ 3.0 ms ] story [ 16.3 ms ] thread1. Rendering performance (how efficient is rendering) 2. Startup speed (how large is our compiler) 3. Preset transition speed (if our compiler is slow, we might drop frames when switching between presets)
I would love to explore compiler optimizations (after all, this project was motivated by an interest in learning about compilers!) but I don't think it's the right thing to pursue yet. Moving Eel evaluation into Wasm was such a large win, that the actual Eel evaluation (the part which we could optimize in our compiler) is now a very very tiny slice of rendering. Most of the remaining time is still spent in WebGL and JavaScript.
Adding optimization passes would slightly increase our bundle size leading to slower startup. If the bundle size increase is minimal, that's probably fine, but trying to pull `wasm-opt` into the browser would probably be a significant increase.
Finally, as you watch the visualizer, it transitions from preset to preset every several seconds. This means that we are running the compiler at the same time as rendering. If optimization passes significantly increase cost of compilation, compiling could cause us to drop frames.
We could avoid this risk by trying to chop compilation up into smaller async tasks, or moving compilation to a web-worker, but that would involve adding some extra complexity to the system.
In summary, if we can speed up the other aspects of rendering to the point where executing the compiled Wasm is the bottleneck optimizations would be an interesting next step, but we would have to weigh them against the potential costs of slower startup and slower compilation.