Performance Upgrades

[zemaj]

Over the past few days we have shipped several changes aimed at making Code feel snappier and lighter on your system. After noticing CPU and memory creeping up last week, we focused on hot paths in core execution, rendering, and I/O. The latest builds reduce overhead without sacrificing functionality or UX, and should smooth out long-running sessions and large outputs.

Every environment is different, though. If Code still feels slower than you’d like on your machine, we’d love your help. Please capture a short CPU profile (and optional memory profile) using the steps below and attach it to a new Discussion with your system details. This helps us zero in on real-world bottlenecks quickly.

How to profile Code on your machine

• Update: pull the latest main or install the latest release.
• Repro: describe what you were doing when it felt slow (commands, file sizes, steps).
• Profile: use one of the platform guides below for ~30–60 seconds while the slowness is visible.
• Share: attach the profile file and the “What to include” info at the end.

macOS (Time Profiler)

• Open Instruments → select Time Profiler → Start recording.
• Launch and use Code to reproduce the slowdown.
• Stop recording → File → Save… (produces a .trace bundle).
• Optional memory: use the Allocations instrument the same way to capture a memory .trace.

Linux (perf + flamegraph)

• Install: sudo apt-get install linux-perf (Debian/Ubuntu) or your distro’s perf.
• Optional flamegraph: sudo apt-get install git && git clone https://github.com/brendangregg/FlameGraph ~/FlameGraph
• Build in release: ./build-fast.sh
• Record for ~60s while reproducing the slowdown:
  • If you start Code from perf: sudo perf record -F 99 -g --
  • If Code is already running: find PID and attach:
    • pidof → sudo perf record -F 99 -g -p -- sleep 60
• Produce a report:
  • Quick: perf report (attach the resulting perf.data plus perf report --stdio output)
  • Flamegraph: perf script | ~/FlameGraph/stackcollapse-perf.pl | ~/FlameGraph/flamegraph.pl > flame.svg (attach flame.svg)

Windows (PerfView)

• Download PerfView.exe (official Microsoft tool).
• Run as Admin → Collect → Run → set “Collect” = default + “Thread Time” checked.
• Command: start Code (or attach to running process under “Collect → Attach to Process”).
• Reproduce the slowdown for ~60s → Stop collection → Save the .etl.zip.
• Optional memory: Collect → GC Only (or enable Heap Snapshot) and save the trace.

What to include with your profile

• Version/commit: git rev-parse --short HEAD and git show -s --format=%ci HEAD
• OS/CPU:
  • macOS: sw_vers and sysctl -n machdep.cpu.brand_string
  • Linux: uname -a and lscpu | sed -n '1,12p'
  • Windows: OS version and CPU model (System Information)
• How you ran Code: exact command or steps.
• Duration: roughly how long you recorded.
• What felt slow: e.g., “streaming 5k-line diffs”, “rapid TUI scrollback”, “spawning shells”, etc.
• Any unusual settings (env vars, large files, remote FS).

Privacy notes

• Profilers may capture command-line args and process names. Close sensitive apps and redact anything private in screenshots before sharing.
• On macOS, Instruments .trace bundles can be large; compress before uploading.

If you're not comfortable sharing your trace publicly you can also email it to code@justevery.com

Thanks for helping us make Code faster on every setup. Real-world profiles are the quickest way for us to confirm and fix performance issues you’re seeing!

[zemaj]

Unfortunately the latest release does have some performance issues, particularly when scrolling. As we've increased the complexity of the TUI it's introduced some latency in the scroll.

Usually I'd hold back a release with this performance, but there's been a considerable number of bug fixes for core issues like compaction, upgrades and limits which I felt were important to release quickly.

We're addressing the performance problems with a fundamental refactor on the core TUI to make it more deterministic and seperate state from rendering - this will also resolve issues with resume, undo and other TUI reconstruction. However, as it's such a major refactor, we don't want to get too far behind upstream so are building it "in-place" keeping existing components working as we replace them with improved version. Once that transition is complete, we'll be able to address the other issues, including performance.

[zemaj]

Turns out there was no real issue! No wonder none of the tests could pick it up!!!!

This solved it! defaults write -g ApplePressAndHoldEnabled -bool false

There must be something about how macOS Tahoe 26.0 handles key presses. Something to do with the new command pallet? Or maybe it was an issue with iTerm2 and upgrading resolved it? Anyone else seeing a lot of 'lag' when pressing keys or scrolling?