Hey everyone 👋
I'm pretty new to this whole AI assistant for code thing, but I'm trying to use Cline on my current project. It's a legacy monolith, and honestly, the codebase is massive.
I started the indexing process, and it seems to just... die after a while. No error message, the terminal window just closes. I'm on a machine with 32GB RAM, so I thought it would be okay.
Has anyone else run into this with really large projects? Is there a config setting or something I'm missing? Maybe a memory limit? I really want to get this working because the bits I've seen are cool, but this is a blocker for me.
Welcome to the world of vendor tools that promise the moon but can't handle real-world loads. You've got 32GB, but have you checked what the process is actually using when it dies? The terminal window closing suggests an unhandled crash, probably memory exhaustion.
The default configs for these tools are built for toy examples and greenfield projects. A legacy monolith will swamp it. You'll need to dig for a config file to set a memory ceiling or, more likely, exclude entire directories from indexing.
They sell you on the "cool bits" but gloss over the fact you need a supercomputer to run it. Check if there's a hidden log file somewhere for a real error.
Show me the unit economics.
The terminal closing without an error is classic out-of-memory behavior. user1590 has a point about checking the process, but you need to look at your operating system's memory monitor while the indexing runs, not just after it crashes.
The 32GB figure is misleading for two reasons. First, these indexing tools often use in-memory graphs that don't scale linearly. Second, you have to account for your OS, IDE, and everything else running. What you perceive as available isn't what's available to the process.
I've seen similar behavior in data pipeline orchestrators when they try to load a full DAG into memory without pagination. The solution there is to break the workload. For Cline, you'll almost certainly need to find a `.clineignore` file or equivalent to exclude build artifacts, vendored dependencies, and maybe legacy modules you don't need indexed right away. Start with a core subset.
data is the product
Yeah, that's a really good point about the in-memory graphs not scaling linearly. It reminds me of when I was first learning about Airflow and tried to parse a massive DAG folder - my laptop just gave up. The system monitor was the only way to see the memory graph climbing until it flatlined.
You mentioned excluding directories like build artifacts. Do you think it's better to start with a broad ignore pattern, like `**/node_modules`, or should you be more surgical and target specific legacy subdirectories first? I'm always unsure where to draw the line between being thorough and keeping the index usable.
rookie