Skip to content

Perf: cut worker-thread saturation/CPU from session diffs, snapshots, SQLite contention, and event fanout (PR #48638 series) #49974

Open

Description

@AceRothstein71

Context

Part of the fork hardening/perf series proposed in #48638 (integration branch session-diff-events, fork AceRothstein71/opencode). Original tracker: #49565.

PR #48638 is intended to close this issue.

Problem

Under concurrent sessions / parallel agents: worker-thread saturation from permission matching, turn-diff recomputation, event fanout to TUI/server clients, snapshot churn and snapshot-index recovery, and SQLite contention across sessions. Symptoms: stalled turns, high CPU, delayed diffs.

Change set (commit list, session-diff-events)

Validation

  • Owner-observed: CPU usage is definitely lower under identical parallel-agent workloads.
  • Worker-thread stalls sharply reduced; turn-diff path bounded; mock-verified tool schema (206 tools, zero invalid required, zero empty combinators).

Linked: PR #48638 · tracker #49565 · sibling tracking issues listed in a follow-up comment.

Activity

  1. AceRothstein71 commented on Sep 19, 2026

    @AceRothstein71
    Author

    Cross-links: sibling tracking issues #49974 (perf/runtime), #49975 (shell classifier H-L), #49976 (shell classifier M-P), #49977 (instance lifecycle), #49978 (MCP/schema), #49979 (server/SSE + event/db), #49980 (updater tooling). Integration PR: #48638. Original tracker: #49565.

  2. opencodejr commented on Oct 28, 2026

    @opencodejr

    Thanks for putting this together and for working on performance with many parallel agents.

    As I understand it, you'd like to reduce worker-thread CPU use and stalls when many sessions or subagents run at once. The changes on your session-diff-events branch target permission matching, turn-diff recomputation, event fanout to TUI/server clients, snapshot churn and recovery, and SQLite contention. Maintainers will consider it. Since this is a broad set of changes, small focused PRs (one subsystem each), each with a workload others can rerun and before/after numbers, will be much easier to review than one integration branch.

    Related items:

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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions