Issue Station
Sign In
Tools hereToolbox

gemini-cli - ✅(Solved) Fix /chat command loading extremely slow with large histories (25s+) [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
google-gemini/gemini-cli#27027•Fetched 2026-05-14 03:45:32
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
N1kky-wedN1kky-wed
Participants
N1kky-wedN1kky-wed
Timeline (top)
labeled ×2cross-referenced ×1

Root Cause

Root causes identified:

  • readline streaming entire files just to extract metadata
  • one wc -l subprocess spawned per file for line counting
  • a separate backward multi-megabyte scan to find the summary field

PR fix notes

PR #27028: perf(sessions): sub-second /chat loading for large session histories

Description (problem / solution / changelog)

Summary

The /chat command took 25+ seconds to load with large session histories. This PR reduces load time to 634ms on a real-world benchmark of 59 sessions / 2.3GB of JSONL.

Details

Three compounding bottlenecks eliminated:

  1. chatRecordingService.ts: New ultra-fast preview path uses raw fd.read() calls (64KB head + 128KB tail). Core metadata is extracted via regex directly on buffers, while the first user message is extracted via line-based JSON parsing to robustly handle nested structures — without streaming the full file.

  2. sessionUtils.ts: Bulk wc -l across all files in a single subprocess call (batched at 100 files) replaces per-file subprocess calls. Windows fallback uses batch-limited (20 concurrent) Node.js buffer scanning to avoid FD exhaustion.

  3. utils.ts: Stable secondary sort by startTime when lastUpdated ties, fixing inconsistent session ordering. Filename timestamp used as reliable startTime fallback instead of mtime.

Note: The 25.62s benchmark was recorded on a fresh environment. In practice, load times frequently exceed 60 seconds on warmed systems with large histories.

Related Issues

Fixes #27027

How to Validate

  1. Generate a large session history (30+ sessions with substantial conversation history recommended — the more messages per session, the larger the files and the more pronounced the improvement)
  2. Run /chat and compare load time against main branch
  3. Verify session list ordering is consistent across multiple opens
  4. On Linux: load time should be under 1 second for typical histories

Note: Windows fallback path (batch-limited buffer scanning) is implemented but not benchmarked on hardware — community validation welcome.

Pre-Merge Checklist

<!-- Check all that apply before requesting review or merging. -->
  • Updated relevant documentation and README (if needed)
  • Added/updated tests (if needed)
  • Noted breaking changes (if any)
  • Validated on required platforms/methods:
    • MacOS
      • npm run
      • npx
      • Docker
      • Podman
      • Seatbelt
    • Windows
      • npm run
      • npx
      • Docker
    • Linux
      • npm run
      • npx
      • Docker

Changed files

  • packages/cli/src/ui/components/SessionBrowser/utils.ts (modified, +7/-2)
  • packages/cli/src/utils/sessionUtils.ts (modified, +167/-88)
  • packages/core/src/services/chatRecordingService.ts (modified, +180/-6)
  • packages/core/src/services/chatRecordingTypes.ts (modified, +2/-0)

Code Example

> /about
CLI Version: 0.42.0
Git Commit: 68e2196d5
Model: gemini-3-flash-preview
Sandbox: no sandbox
OS: Linux
Auth Method: Signed in with Google
Tier: Gemini Code Assist in Google One AI Pro
RAW_BUFFERClick to expand / collapse

What happened?

The /chat command takes 25+ seconds to load when a user has a large session history. On a real-world benchmark of 59 sessions / 2.3GB of JSONL, loading consistently takes over 25 seconds, making the feature practically unusable.

Root causes identified:

  • readline streaming entire files just to extract metadata
  • one wc -l subprocess spawned per file for line counting
  • a separate backward multi-megabyte scan to find the summary field

What did you expect to happen?

/chat should load session history in a reasonable time regardless of history size. With a fix addressing all three bottlenecks, load time drops from 25.62s to 634ms on the same 59 sessions / 2.3GB benchmark.

Client information

<details> <summary>Client Information</summary>

Run gemini to enter the interactive CLI, then run the /about command.

> /about
CLI Version: 0.42.0
Git Commit: 68e2196d5
Model: gemini-3-flash-preview
Sandbox: no sandbox
OS: Linux
Auth Method: Signed in with Google
Tier: Gemini Code Assist in Google One AI Pro
</details>

Login information

Google Account (Signed in with Google)

Anything else we need to know?

I have a complete fix ready addressing all three bottlenecks with full cross-platform support (Linux/macOS/Windows). Happy to open a PR immediately once this issue is acknowledged.

Benchmark (59 sessions / 2.3GB of JSONL):

  • Current main: 25.62s
  • With fix: 634ms

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#prompt template#agent execution#callback error#memory management#API rate limit

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING