Hey everyone! 👋 I've been living with Tabnine across three different dev machines this year, and I've found that its default cache behavior can sometimes feel a bit... hungry, especially on my mid-tier 16GB RAM laptop. After wrestling with occasional slowdowns during my database migration scripting (we're talking hundreds of SQL and Python ETL files), I spent a good chunk of last week fine-tuning Tabnine's cache settings. I wanted to share a configuration that's given me the best balance between snappy suggestions and keeping my system responsive for other tasks, like running local Postgres instances and MongoDB services.
The main goal is to shift the balance from pure speed (which uses more RAM) to being more memory-conscious. Here's the breakdown of what I adjusted and why.
**Key Settings & Rationale:**
* **Local Index Cache Size (`local_index_cache_size_mb`):** This is the big one. It controls how much of your project's code is held in memory for super-fast suggestions. The default can be aggressive.
* **My Adjustment:** I scaled this back from the auto-configured value (which was eating over 2GB on my large monorepo) to a fixed 1024 MB.
* **Why:** This keeps the index performant for active files and recent work without claiming everything.
* **Remote Model Cache Size (`remote_model_cache_size_mb`):** This caches the larger AI models downloaded from Tabnine's servers.
* **My Adjustment:** I left this at its default (or sometimes set it to 512 MB explicitly) as it's less of a concern for my typical workflow.
* **Why:** The remote models are crucial for broader, more contextual suggestions, and I found reducing this too much hurt completion quality.
* **Disabling "Deep Completions" for Large Contexts:** This isn't a cache setting per se, but it drastically reduces unexpected memory spikes.
* **How:** In your project's `.tabnine_config.json`, you can add rules to disable the more resource-intensive completions for certain file patterns or beyond a certain context length.
Here's a look at the `.tabnine_config.json` I'm using in the root of my current data pipeline project:
```json
{
"local_index_cache_size_mb": 1024,
"remote_model_cache_size_mb": 512,
"completion_behavior": {
"disable_deep_completions_for_context_length_above": 2048
},
"file_patterns": {
"disable_deep_completions": ["*.sql", "*.jsonl", "*.log"]
}
}
```
**The Impact & Pitfalls to Avoid:**
* **Result:** My IDE (VS Code) feels noticeably smoother when switching between large files. Tabnine's memory footprint stays more predictable, usually between 1.5GB - 2GB during heavy use, instead of spiking towards 3GB+.
* **Trade-off:** The initial indexing of a fresh project might feel a tiny bit slower, and suggestions for very large, single files (like a massive 5000-line SQL dump) might not be as comprehensive. For me, this is a worthy trade-off.
* **Big Pitfall:** Don't just slash all cache values blindly! Setting `local_index_cache_size_mb` too low (like 256 MB) made Tabnine almost useless for my larger projects, as it couldn't keep enough context to be helpful. Start by trimming 25-30% from the defaults and observe.
If you're also on a 16GB machine and juggling database clients, Docker containers, and an IDE, I highly recommend experimenting. The defaults are tuned for performance, not necessarily for a crowded multitasking environment. Let me know if you've found other tweaks that help!
—B
Backup first.