startup painfully slow (~40s) in certain conditions

[rafal0p]

Description

opencode startup started to be painfully slow (~40s) in certain conditions.

Problem shows when working directory contains many subdirectories (e.g. a parent dir with hundreds of git repos).

What's the real-life usecase? In our company we have hundreds of microservices and oftentimes to achieve a goal you need to touch a few. I have all of them cloned locally just in case, and always open opencode from main directory.

I narrowed down the culprit to v1.4.4, I'm almost sure it's #21703. The PR says that we switch to WASM but not why. @nexxeln what was your usecase?

Plugins

none (reproduced with empty config)

OpenCode version

1.4.6 (regression since 1.4.4)

Steps to reproduce

# Download v1.4.3
cd /tmp && curl -sL https://github.com/anomalyco/opencode/releases/download/v1.4.3/opencode-darwin-arm64.zip -o oc143.zip && unzip -o oc143.zip -d oc143

# Download v1.4.4
cd /tmp && curl -sL https://github.com/anomalyco/opencode/releases/download/v1.4.4/opencode-darwin-arm64.zip -o oc144.zip && unzip -o oc144.zip -d oc144

# Run benchmarks
cd ~/large-directory-with-many-repos
time /tmp/oc143/opencode debug skill > /dev/null 2>&1   # ~2.7s
time /tmp/oc144/opencode debug skill > /dev/null 2>&1   # ~54s

Screenshot and/or share link

No response

Operating System

macOS (Apple Silicon)

Terminal

iTerm2

[AlanIWBFT]

Yes, it's exactly it. It's because the ripgrep WASM code is executed on the main thread in Bun which blocks the entire JS runtime, even if the interfaces at js level are designed to be async. When that's happening, even an inspector debugger cannot pause the excution. What it is doing is scanning your entire workspace's files to provide searching functionalities. It is triggered by File.Service.init() -> rg.files(). On Windows it's worse as Windows has heavier filesystem driver stack/antivirus. The JS runtime cannot be unblocked until your entire workspace is scanned.
Meanwhile, it is also a bad architectural choice in terms of security. In the past with a standalone rg.exe I can simply exclude/setting 'performance' mode for it specifically in antivirus to get high fs perf without whitelisting the entire opencode[-cli].exe. rg.exe does pure file reading and is very hard to exploit. opencode on the other hand, is a scripting host and can do much more. Now... it's just bad since if you want perf you have to broaden the attack surface. You lose the safety from process isolation.

[AlanIWBFT]

If you're interested, I've replaced WASM ripgrep with rg.exe, alone with a handful of fixes in my fork: https://github.com/AlanIWBFT/opencode

[rafal0p]

Case closed, @nexxeln thanks for rolling it back (#22773)!