Skip to content

fix: Add periodic Kitty image garbage collection during scroll - #432

Closed
kaantradelab wants to merge 1 commit into
migueldeicaza:mainfrom
kaantradelab:fix/kitty-image-gc
Closed

fix: Add periodic Kitty image garbage collection during scroll#432
kaantradelab wants to merge 1 commit into
migueldeicaza:mainfrom
kaantradelab:fix/kitty-image-gc

Conversation

@kaantradelab

Copy link
Copy Markdown

Problem:
When using Kitty graphics protocol, orphan images accumulate in kittyGraphicsState.imagesById because cleanupUnusedKittyImages() is only called on explicit delete commands.

During long-running terminal sessions with heavy output (e.g., CI/CD logs, AI agent sessions), this causes memory to grow unbounded. Observed: 11GB+ memory usage, terminal freeze, inability to scroll.

Solution:

  • Add counter-based garbage collection in scroll()
  • Track lines scrolled since last cleanup
  • Trigger cleanupUnusedKittyImages() every 500 lines when buffer is trimmed
  • Change function visibility from private to internal

Results:

  • Memory usage reduced from 11GB+ to ~400MB (96%+ improvement)
  • Terminal remains responsive during long sessions

Problem:
When using Kitty graphics protocol, orphan images accumulate in
`kittyGraphicsState.imagesById` because `cleanupUnusedKittyImages()`
is only called on explicit delete commands.

During long-running terminal sessions with heavy output (e.g., CI/CD
logs, AI agent sessions), this causes memory to grow unbounded.
Observed: 11GB+ memory usage, terminal freeze, inability to scroll.

Solution:
- Add counter-based garbage collection in `scroll()`
- Track lines scrolled since last cleanup
- Trigger `cleanupUnusedKittyImages()` every 500 lines when buffer is trimmed
- Change function visibility from `private` to `internal`

Results:
- Memory usage reduced from 11GB+ to ~400MB (96%+ improvement)
- Terminal remains responsive during long sessions

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@migueldeicaza

Copy link
Copy Markdown
Owner

Oops, thank you so very much for tracking this!

Let me see if I can do something a little more aggressive, rather than doing a cycle scan every N scrolled lines, if that does not pan out, I will merge your PR.

@migueldeicaza

Copy link
Copy Markdown
Owner

Btw, the reason I do not want to do a collection after the number of lines is both that it would add another layer of uncertainty and jumps while I am profiling the performance and because it would probably break the kitty protocol.

Since reference counting does not work (as this is part of the design), what I am going to do is add an eviction of data after certain size.

@migueldeicaza

Copy link
Copy Markdown
Owner

Ok, this is what I am doing instead:

#433

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.

2 participants