How octorus Renders 300K Lines of Diff at High Speed

In a previous post , I introduced my TUI tool. This time, I'd like to talk about the performance optimizations behind octorus . What Do We Mean by "Fast"? "Fast" can mean many things. Even just for rendering, there's initial display speed, syntax highlighting speed, scroll smoothness (fps), and more. Perceived speed and internal speed aren't always the same. No matter how much you optimize with zero-copy or caching, if the PR is massive, the API call becomes the bottleneck. And without rendering-level optimizations, the UI can freeze entirely. In octorus, I push internal optimizations as far as possible while also applying web-app-style thinking (FCP / LCP / INP) to the TUI. Core Concept The fundamental approach is to asynchronously build and consume caches based on the current display state. By maintaining 5 layers of caching , the perceived initial display time approaches 0ms, while also improving fps and minimizing allocations. Session Cache for PR Data PR data is fetched via gh api