# Memory Management Strategy in code-review-graph for Large Codebases

> Discover code review graph's memory management strategy for large codebases. Learn how WAL mode, dynamic truncation, and on-demand queries prevent memory exhaustion for efficient analysis.

- Repository: [Tirth Kanani/code-review-graph](https://github.com/tirth8205/code-review-graph)
- Tags: performance
- Published: 2026-08-15

---

**The code-review-graph extension uses a read-only SQLite database with Write-Ahead-Log (WAL) mode, dynamic truncation via `maxNodes` limits, and on-demand queries to prevent memory exhaustion when analyzing large codebases.**

The `code-review-graph` project, available at `tirth8205/code-review-graph`, tackles the challenge of visualizing code relationships in massive repositories without crashing VS Code. Its memory management strategy combines **persistent on-disk storage** with **lazy data loading** and **configurable safeguards**, ensuring the extension remains responsive even when analyzing millions of lines of code.

## Core Architecture: SQLite as the Memory Safety Net

At the heart of the strategy lies a **read-only SQLite database** built by the Python backend. Rather than holding the entire code-analysis graph in memory, the extension queries this database through the `SqliteReader` class in [`src/backend/sqlite.ts`](https://github.com/tirth8205/code-review-graph/blob/main/src/backend/sqlite.ts).

The database connection is optimized for minimal memory footprint:

- **WAL journal mode** enables non-blocking reads while preventing memory bloat from traditional rollback journals
- **5-second busy timeout** prevents indefinite locks without consuming resources
- **Automatic cleanup** when the extension deactivates

```typescript
// src/backend/sqlite.ts#L84-L88 — SqliteReader constructor
this.db = new Database(dbPath, { readonly: true });
this.db.exec("PRAGMA journal_mode = WAL");
this.db.exec("PRAGMA busy_timeout = 5000");

```

## Three Layers of Memory Protection

The extension implements three complementary safeguards against memory exhaustion.

### 1. Configurable Node Truncation

The backend enforces a hard limit on nodes transmitted to the webview via the `maxNodes` setting. When truncation occurs, the UI warns users and invites them to adjust their configuration.

In `src/webview/graph.ts#L56-L61`, the webview handles this gracefully:

```typescript
if (message.truncated) {
  showWarning(
    `Graph truncated to ${message.maxNodes} nodes. ` +
    `Increase "codeReviewGraph.maxNodes" in settings to see more.`
  );
}

```

Users control this limit in their VS Code settings:

```json
{
  "codeReviewGraph.maxNodes": 2000
}

```

### 2. On-Demand Query Execution

Rather than materializing the full graph, the webview requests precisely the data it needs through parameterized `SqliteReader` methods.

The `getEdgesAmong` method in `src/backend/sqlite.ts#L33-L38` demonstrates efficient bulk-parameter handling:

```typescript
const qualifiedNames = new Set<string>(["src/main.ts", "src/util.ts"]);
const edges = sqliteReader.getEdgesAmong(qualifiedNames);

```

This approach scales to large parameter lists without constructing massive intermediate arrays.

### 3. File-Scoped Lazy Loading

Individual file navigation triggers targeted queries via `getNodesByFile`, ensuring only relevant nodes enter memory:

```typescript
const filePath = "/src/app.ts";
const nodes = sqliteReader.getNodesByFile(filePath);

```

## Key Implementation Files

| File | Purpose |
|------|---------|
| [`src/backend/sqlite.ts`](https://github.com/tirth8205/code-review-graph/blob/main/src/backend/sqlite.ts) | Core reader with WAL mode, lazy query methods, and connection lifecycle management |
| [`src/webview/graph.ts`](https://github.com/tirth8205/code-review-graph/blob/main/src/webview/graph.ts) | Webview logic for truncated data handling and D3 graph rendering |
| [`package.json`](https://github.com/tirth8205/code-review-graph/blob/main/package.json) | Extension manifest defining the `maxNodes` user setting |

## Performance Characteristics

According to the source code implementation in `tirth8205/code-review-graph`, this strategy delivers:

- **Predictable memory ceiling** — bounded by `maxNodes` rather than codebase size
- **Sub-second query response** — WAL mode and prepared statements minimize I/O overhead
- **Zero memory leaks on deactivation** — explicit connection cleanup in `SqliteReader.dispose()`

## Summary

- **SQLite WAL mode** provides fast, read-only access without memory-heavy journaling
- **`maxNodes` truncation** creates a configurable safety valve for webview memory
- **On-demand queries** via `getNodesByFile` and `getEdgesAmong` prevent eager loading
- **Automatic resource cleanup** ensures connections close when VS Code exits

## Frequently Asked Questions

### What happens when code-review-graph analyzes a codebase larger than the maxNodes limit?

The backend truncates the graph to the configured `maxNodes` value (default 1000) and transmits a `truncated: true` flag. The webview displays a warning banner with instructions to increase the limit in VS Code settings. The database itself contains the complete analysis; only the visualization is capped.

### Why does code-review-graph use SQLite instead of in-memory data structures?

SQLite provides **persistent, queryable storage** that scales independently of VS Code's JavaScript heap. The WAL journal mode enables concurrent read access without copying data into memory, and parameterized queries allow precise data retrieval without materializing entire relations.

### How can I increase the memory limit for larger codebases?

Modify your VS Code settings to raise `codeReviewGraph.maxNodes`. The backend will transmit more nodes to the webview, though you should balance this against available system memory and D3 rendering performance. There is no hard upper bound enforced by the extension.

### Does the SQLite connection remain open and consume memory continuously?

No. The `SqliteReader` constructor in [`src/backend/sqlite.ts`](https://github.com/tirth8205/code-review-graph/blob/main/src/backend/sqlite.ts) sets a 5-second busy timeout, and the connection closes automatically when the extension deactivates. The read-only WAL configuration ensures the connection remains lightweight even during extended VS Code sessions.