High CPU usage (~20%) compared to Claude (~3%) #805

Activity

1. kanaka commented on Jul 9, 2025

   

   kanaka

   on Jul 9, 2025

   More actions

   I am also seeing this behavior on Ubuntu 22.04. In addition, typing is slow to echo the characters (sometimes really slow although I'm not sure what triggers the really slow response times).
2. adamdotdevin commented on Jul 10, 2025

   

   adamdotdevin

   on Jul 10, 2025

   Member

   More actions

   @netanelbi has this always been the case for you or a recent regression?
3. thdxr

   self-assigned this

   on Jul 10, 2025
4. netanelbi commented on Jul 10, 2025

   

   netanelbi

   on Jul 10, 2025

   Author

   More actions

   i am not sure, i didn't check before. i asked agent-zero to analyze the repo the other day, he pointed me at the file watcher that in versions 172-176 was introduced and that now its only in the "tui" process. it said it might be pulling too frequently and/or its not the best to use and proposed chokidar.

   here the analysis Agent-Zero using gpt-4.1:

   
   Root Cause of High CPU Usage in sst/opencode (v0.1.172–v0.1.176)
   
       A new FileWatcher module was added, using Node's
       fs.watch
       recursively on the working directory.
       On Ubuntu, this approach is very CPU-intensive, especially in large directories or with frequent file changes (e.g., logs, temp files from LLMs).
       The event handler is not throttled or debounced, so many file events can overwhelm the process and spike CPU usage.
       No direct changes to LLM API or configuration menu were found, but the FileWatcher indirectly impacts performance.
   
   Suggested fixes:
   
       Throttle or debounce the file event handler.
       Limit the scope of watched files/directories.
       Use a more efficient watcher library (e.g., chokidar).
       Audit consumers of the file event for heavy processing.
   
   Summary:
   The new file watching logic is the most likely cause of the high CPU usage. Rolling back to a version before v0.1.176 or applying the above fixes should mitigate the issue.
   
   

   
   In the latest sst/opencode releases (up to v0.2.15), the file watcher is now started only for the terminal UI (TUI), which may reduce unnecessary CPU usage in other modes. However, there is no explicit mention of a full fix (such as throttling, debouncing, or switching to a more efficient watcher) in the changelog, and the official GitHub issue (#679) remains open with no confirmation of a complete resolution.
   
   Conclusion:
   
       The high CPU usage issue caused by the file watcher is likely still present in the latest version, especially when using the TUI on Ubuntu in large directories.
       The problem may be less severe outside the TUI, but is not fully fixed.
       If you are affected, consider limiting the size of watched directories, using a non-TUI mode, or monitoring the GitHub issue for future updates.
   
   

   To fix the high CPU usage caused by the FileWatcher in sst/opencode, consider the following:
   
       Switch to chokidar
           Replace Node's built-in
           fs.watch
           with [chokidar](https://github.com/paulmillr/chokidar), which is more efficient and handles platform-specific quirks.
           Example:
   
           // Replace
           // fs.watch(directory, { recursive: true }, handler)
           // With
           const chokidar = require('chokidar');
           const watcher = chokidar.watch(directory, { ignoreInitial: true });
           watcher.on('all', (event, path) => {
             // handle event
           });
   
       Throttle or debounce the event handler
           Use a debounce function to limit how often your handler runs:
   
           const debounce = (fn, delay) => {
             let timer;
             return (...args) => {
               clearTimeout(timer);
               timer = setTimeout(() => fn(...args), delay);
             };
           };
           watcher.on('all', debounce((event, path) => {
             // handle event
           }, 200)); // 200ms debounce
   
       Limit the scope of watching
           Only watch directories/files that are necessary for your application, not the entire working directory.
           Exclude large or noisy directories (e.g., [node_modules](https://ao.098742.xyz/#), .git, logs, temp files) using chokidar's
           ignored
           option:
   
           const watcher = chokidar.watch(directory, {
             ignoreInitial: true,
             ignored: /node_modules|\.git|logs|tmp/
           });
   
       Audit event consumers
           Ensure that any code responding to file events is efficient and does not perform heavy processing in response to every event.
   
   Summary:
   
       Use chokidar for efficient, cross-platform file watching.
       Debounce or throttle event handlers to prevent event storms.
       Limit the scope of watched files/directories.
       Audit downstream consumers for performance.
   
   These changes should significantly reduce CPU usage and improve responsiveness, especially on Ubuntu and in large projects.
   
5. netanelbi commented on Jul 10, 2025

   

   netanelbi

   on Jul 10, 2025

   Last edited by netanelbi

   Author

   More actions

   idle after startup ( home directory):

   

   while the chat writes text (1k words story request):

   
6. thdxr commented on Jul 10, 2025

   

   thdxr

   on Jul 10, 2025

   Member

   More actions

   can you check v0.2.25 to see if it's better
7. netanelbi commented on Jul 11, 2025

   

   netanelbi

   on Jul 11, 2025

   Author

   More actions

   the root folder issue with the rg process is not happening any more, it was resolved already in version before 2.25, maybe the one with the .git detection for me.
   idle CPU is ok now.
   it still consume about 16-17% while the TUI is rendering text, like if i ask the model to spit out 1k of words you can easily see the CPU usage
8. netanelbi commented on Jul 19, 2025

   

   netanelbi

   on Jul 19, 2025

   Author

   More actions

   in latest version 0.3.22 the TUI process takes around 30% cpu on my machine. at least now it achieve similar speed as other methods but i dont think more than 5% is acceptable.
   claude code uses less than 3%, the rendering is very problematic. @thdxr
9. adamdotdevin commented on Jul 19, 2025

   

   adamdotdevin

   on Jul 19, 2025

   Member

   More actions

   @netanelbi im going to merge this into #811 bc there's more dialog there and to simplify tracking; we're actively working on this, will get it right
10. adamdotdevin

    closed this as a duplicateof Text rendering is VERY slow (and CPU usage is really high even when idle) #811 on Jul 19, 2025