Skip to content

Performance: FileStore.saveEvent does synchronous file open/lock/write/close on every enqueue and dequeue #60

Description

@jonbaldie

Finding — O(1) per call, but ~30–43 μs synchronous blocking I/O on the hot path

Subsystem: Persist (src/persist.ts:22–37)

Current complexity

  • Time: O(1) per call, but ~30–43 μs of synchronous blocking I/O
  • Space: O(1)

Cause

Each saveEvent opens the file (Deno.openSync), acquires a file lock (lockSync), writes one line, unlocks, and closes — all synchronous, on the hot path of every enqueue and dequeue HTTP request. This blocks the event loop, serializing concurrent requests.

Evidence

Operations FileStore MemoryStore
1 0.043 ms 0.001 ms
1,000 31.08 ms (31 μs/op) 0.044 ms (0.044 μs/op)

FileStore is ~700× slower per operation. At 1,000 req/s, this is ~31 ms/s of blocked event loop (3.1% of capacity consumed by sync I/O).

Runtime: Deno 2.7.6, V8 14.6.202.9-rusty, darwin (Apple Silicon)

Remediation direction

Keep the file handle open (open once, reuse); use buffered/batched writes; or use async I/O (Deno.open, file.write) to avoid blocking the event loop.

Confidence

High — source analysis + benchmark. This is a constant-factor (latency) concern, not an asymptotic one, but it is the per-request bottleneck with the highest real-world impact at scale.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions