Performance

[Robert-MacWha]

Mega-issue describing various performance aspects of the framework.

[Robert-MacWha]

Real-world Performance analysis

Architecture overview

sequenceDiagram
    participant main as Main
    participant vp as Vault Page
    participant v as Vault
    participant revm as REVM Provider
    participant rpc as RPC Provider

    main ->> vp: Click Get Assts
    vp ->> v: vault_get_assets
    v ->> revm: get_native
    v ->> revm: get_erc20
    v ->> revm: get_erc20
    loop: Many Simulation requests
        revm ->> rpc: Simulation request
        rpc ->> main: req()
        main -->> rpc: resp()
        rpc -->> revm: Resp
    end
    revm -->> v: native
    revm -->> v: erc20
    revm -->> v: erc20
    v -->> vp: assets
    vp ->> main: Update main
    main -->> vp:
    vp -->> main: Return

Loading

Performance Overview

• Test environment: Chrome V8
• End-to-end 1.6-2s
  • Down from ~40s with old wasmi-based runtime
• Breakdown:
  • 25 network requests
  • ~1.5s waiting on network I/O (concurrently, so not 1.5s blocking)
  • 29 plugin instances
  • Peak of 9 concurrent plugin instances (compute workers, 11 including main + coordinator)
  • 40-100ms spawn time per plugin instance
  • ~5ms compute time per plugin instance
  • Workers:
    • Main busy 37%
    • Coordinator busy 11%
    • W0 busy 92%
    • W1 busy 91%
    • W2 busy 87%
    • W3 busy 74%
    • W4 63%
    • W5 52%
    • W6 39%
    • W7 40%
    • W8 33%
    • W9 27%

Bottlenecks

1. Main thread round-trip latency (largest potentially controllable)

• Each plugin request requires at least 8 hops to fufill
  • Make request: worker -> coordinator -> main
  • Spawn handler instance: main -> coordinator -> worker
  • Resp: worker -> coordinator -> main -> coordinator -> worker
• Hops between coordinator<>worker are essentially free
• Hops between coordinator<>host take 5-10s
• Consider allowing workers to respond to requests through the coordinator, instead of through main? Saves 2 post_messages

2. Compute worker spawning

• Static delay of ~10ms between when coordinator receives a request and the compute worker starts.
  • Probably due to transfering the module / relying on post_message for compute worker dispatch.
  • TODO: Queue Modules in compute workers, only requesting them from the coordinator / host if missing.

3. Browser network Stack (largest overall)

• "Queueing and connecting" up to 130ms (on overall req time of ~250ms)
• Caused by: HTTP/1.1 connection limits (6/domain), DNS, TLS handshakes
• Aim to combine / reduce network requests whenever possible.