Skip to content

Conversation

@taetaetae
Copy link

@taetaetae taetaetae commented Jan 30, 2026

Problem

During streaming responses, OpenCode writes to storage (JSON files) on every reasoning-delta event. With fast streaming APIs, this results in hundreds of file writes per second, causing:

  1. High I/O overhead from frequent file system operations
  2. Increased latency between receiving content and displaying it
  3. Slower perceived response time compared to native CLI tools (e.g., kiro-cli)

Fixes #11329

Analysis

I compared OpenCode with kiro-cli using the same Kiro API:

Aspect kiro-cli OpenCode
API endpoint Same (q.us-east-1.amazonaws.com) Same
TTFB 2-10s 2-10s
Delta handling Memory only File write per delta
Perceived speed Fast Slower

The bottleneck is in processor.ts:

case "reasoning-delta":
  if (part.text) await Session.updatePart({ part, delta: value.text })
  // This writes to file system on EVERY delta!

Session.updatePart calls Storage.write which does:

await Bun.write(target, JSON.stringify(content, null, 2))

Solution

Implement throttled storage writes for reasoning-delta events:

  • Accumulate content in memory (already happening via part.text +=)
  • Only flush to storage every 50ms (STREAMING_UPDATE_THROTTLE_MS)
  • Always flush on reasoning-end to ensure data persistence
  • No change to final content or persistence guarantees

Expected Impact

  • ~20x fewer file writes during streaming (assuming 1 delta/2.5ms average)
  • Reduced I/O overhead and CPU usage
  • Faster perceived response time
  • No change to final message content

Changes

  • Added STREAMING_UPDATE_THROTTLE_MS constant (50ms)
  • Added throttle state tracking (lastUpdateTime, pendingReasoningUpdates)
  • Modified reasoning-delta handler to throttle storage writes
  • Ensured reasoning-end always flushes pending updates

…/O overhead

## Problem

During streaming responses, OpenCode writes to storage (JSON files) on
every reasoning-delta event. With fast streaming APIs, this results in
hundreds of file writes per second, causing:

1. High I/O overhead from frequent file system operations
2. Increased latency between receiving content and displaying it
3. Slower perceived response time compared to native CLI tools

## Analysis

Comparing OpenCode with kiro-cli using the same Kiro API:
- Both receive streaming responses with similar TTFB (2-10s)
- kiro-cli renders directly to terminal (memory only)
- OpenCode writes every delta to storage via Session.updatePart()

The bottleneck is in processor.ts:
```typescript
case "reasoning-delta":
  if (part.text) await Session.updatePart({ part, delta: value.text })
  // This writes to file system on EVERY delta!
```

## Solution

Implement throttled storage writes for reasoning-delta events:
- Accumulate content in memory (already happening via part.text +=)
- Only flush to storage every 50ms (STREAMING_UPDATE_THROTTLE_MS)
- Always flush on reasoning-end to ensure data persistence
- No change to final content or persistence guarantees

## Expected Impact

- ~20x fewer file writes during streaming
- Reduced I/O overhead
- Faster perceived response time
- No change to final message content
@github-actions
Copy link
Contributor

Hey! Your PR title perf(processor): Throttle storage writes during streaming to reduce I/O overhead doesn't follow conventional commit format.

Please update it to start with one of:

  • feat: or feat(scope): new feature
  • fix: or fix(scope): bug fix
  • docs: or docs(scope): documentation changes
  • chore: or chore(scope): maintenance tasks
  • refactor: or refactor(scope): code refactoring
  • test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

@github-actions
Copy link
Contributor

The following comment was made by an LLM, it may be inaccurate:

No duplicate PRs found

@taetaetae taetaetae changed the title perf(processor): Throttle storage writes during streaming to reduce I/O overhead fix(opencode): Throttle storage writes during streaming to reduce I/O overhead Jan 30, 2026
@github-actions
Copy link
Contributor

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

  1. Open an issue describing the bug/feature (if one doesn't exist)
  2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

@rekram1-node
Copy link
Collaborator

we are moving to sqlite

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Slow perceived response time due to excessive storage writes during streaming

2 participants