Rendering large sessions is extremely slow (>30s for ~2800 messages)

[jensenojs]

Switching to a session with ~2800 messages (~9300 parts, ~87000 rendered lines) freezes the UI for 30+ seconds.

Profiled on a session with 2786 messages, 9312 parts, 86946 rendered lines:

Phase	Time	%
API fetch	~1900ms	5%
Format (Lua)	437ms	1.2%
nvim_buf_set_lines	788ms	2.2%
Extmarks	69ms	0.2%
Fold creation (cursor + normal! zc/zo)	35,266ms	96.5%

The bottleneck is output_window.set_folds() — it iterates through fold ranges calling vim.fn.cursor() + vim.cmd('silent! normal! zc') for each one. With 392 folds in an 87K-line buffer, each cursor + zc triggers a screen redraw (~90ms per fold). A second pass restoring previously-open folds (zo) doubles the cost.

for _, range in ipairs(folds.ranges) do
  vim.fn.cursor(range.from, 1)
  vim.cmd('silent! normal! zc')
end

[jensenojs]

On-demand rendering is also a potential solution

[jensenojs]

Fix (PR pending)

Two root causes, reducing render time from ~36s → ~3s on the same session.

cursor() + normal! zc/zo → :{from},{to}fold: vim.fn.cursor() in an 87K-line buffer triggers a screen redraw (~90ms per fold). Using Ex commands instead avoids cursor movement. Also temporarily switch to foldmethod=manual so :fold doesn't trigger foldexpr recalculation.

Keep foldmethod=manual instead of switching back to expr: Switching back causes Neovim to re-evaluate foldexpr for all 86946 lines (Vimscript→Lua bridge, ~4.6s). Since set_folds/update_part_folds already manage folds explicitly during rendering, the expr method is unnecessary after initial setup.

Phase	Before	After
Fold creation (cursor+zc)	~35,266ms	—
Fold creation (:{range}fold)	—	~0.4ms
Switch back to foldmethod=expr	~4,600ms	removed
Total	~36,000ms	~3,068ms

Remaining bottleneck after the fold fix:

Phase	Time	Notes
API fetch	~1626ms	Backend side
nvim_buf_set_lines (86946 lines)	~840ms	Full-buffer write cost
Flush overhead	~400ms	set_all_folds() rebuilds all folds on every part update
Format (Lua)	~36ms
Extmarks	~74ms
Folds	~0.8ms	Fixed
Total	~3,068ms

The 840ms set_lines cost could only be addressed by on-demand rendering (only format/write visible lines).

[jensenojs]

Update: lazy rendering

The 840ms set_lines bottleneck mentioned above is now addressed. Instead of formatting and writing all messages, we only render enough to fill the output window initially (~11 messages for a typical layout), and load more on scroll-to-top.

Same 2786-message session:

• Fetch: ~1865ms (async, doesn't block UI)
• Render: ~10ms (was ~1300ms)
• Scroll-to-top load more: ~14ms

The max_messages infrastructure (<leader>otm) already existed but required manual toggle. This change makes it automatic — the initial render uses a viewport-based limit calculated from window height (ceil(height / 5 * 1.5)), and WinScrolled triggers load_more_messages() when the cursor reaches the top.

Both fixes are on the fix/render-perf branch, PR pending.