Cora Code Performance: Benchmarking 50K-Line Codebases

How fast is Cora Code in the real world? We benchmarked it against repos from 1K to 50K lines. Results and optimization insights.

Cora Code Performance: Benchmarking 50K-Line Codebases

Benchmarking Cora Code on 50,000 Lines of Production Code

We benchmarked Cora Code across real production codebases totaling over 17,000 symbols and 2,000+ files. Here are the actual numbers, not marketing claims.

The Test Environment

Six repositories across five programming languages, all indexed into a single Cora database:

  • cora-code (Rust): 1,734 symbols, 111 files
  • uteke (Rust): 1,564 symbols, 137 files
  • bond (Go): 1,584 symbols, 504 files
  • dailygem-mobile (Dart): 442 symbols, 83 files
  • shadcn-sveltekit-landing-page (Svelte): 429 symbols, 292 files
  • cora-api (Rust + TypeScript/Svelte): 10,968 symbols, 685 files

Total: 17,000+ symbols, 2,000+ files, multi-language. All sharing one SQLite database and one usearch vector index.

Indexing Performance

  • Full rebuild (1,734 Rust symbols): 5.3 seconds
  • Incremental re-index (no changes): reports 0 indexed, N skipped (existing index intact)
  • Embedding generation: 0.7 microseconds per symbol
  • Multi-project isolation: project_id FK ensures zero cross-contamination

Search Performance

  • Brain search (warm cache): 37ms
  • Brain search (cold start): 52ms
  • usearch KNN query: ~25ms (68% of search time)
  • FTS5 keyword query: ~5ms
  • Graph BFS (depth-2): ~7ms
  • 50 queries per session: ~1.8 seconds total overhead

The bottleneck is usearch vector search, which accounts for 68% of Brain Mode latency. This is expected — HNSW approximate nearest neighbor search over 17,000 vectors in 256 dimensions is the most computationally expensive step.

Review Performance

  • Small diff (<100 lines): 15-30 seconds (LLM-bound)
  • Medium diff (100-200 lines): 30-60 seconds
  • Large diff (200+ lines, 4+ files): 60-120+ seconds
  • Static scan (deterministic rules only): 2-5 seconds regardless of size

Review performance is LLM-bound, not Cora-bound. The diff processing, context extraction, and prompt construction add negligible overhead. The bottleneck is waiting for the LLM API response.

Model Quality Comparison

We tested two GLM models on the same codebase. The difference was stark:

  • glm-4-plus: 28 false positives on identical code
  • glm-5.2: 0 false positives on identical code

This is why BYOK matters. A single model swap turned a noisy, unusable review into a clean, actionable one. If you are locked into a SaaS tool's model choice, you cannot make this adjustment.

Scalability

The single-file SQLite database (WAL mode) handles 17,000+ symbols with no lock contention. File size stays manageable. The usearch index grows linearly with symbol count. We see no practical limit for individual developer use cases. Team-scale deployment with shared indexes is planned for a future release.

Memory Usage

  • Static token embeddings: ~30MB vendored (feature-gated, not included in default builds)
  • usearch index: scales at ~1KB per 256d vector
  • SQLite database: ~2MB for 17,000 symbols
  • Runtime RAM: under 50MB for typical usage

Cora Code is designed to be lightweight. No GPU required, no large model downloads, no background services. It runs as a single binary.