# Starboard optimization case study

> Canonical page: https://codevetter.com/benchmark/optimization/starboard

A plausible incremental token scanner passed focused correctness but ran slower, so CodeVetter rejected it and restored the original code.

## Result

- Decision: rejected
- Observation date: 2026-08-14
- Primary metric: Largest tested catalog — 5.3% slower
- Measurement note: 47.496 → 50.026 ms/op
- Availability: Uses the current local Vitest performance path.

## Tested boundary

- Flow: src/__tests__/project-recommendations-performance.test.ts — project recommendations scale across local catalog sizes
- Source: src/lib/project-recommendations.ts:101
- Revision: 7af23ce31ac10c7c552713f92985934de116abee
- Correctness: 13 focused tests passed before performance rejected the candidate.
- Patch cost: 1 file, 19 gross changed lines, net 5, 0 production dependencies

## Decision path

- **Tokenization appeared in the CPU profile (observed):** 10.8% of CPU samples pointed at meaningfulTokens.
- **Incremental regular-expression scan (tested):** The one-file experiment stayed within the change-cost budget and passed focused correctness.
- **Slower and too noisy to trust (rejected):** The candidate was slower, sample spread was high, allocation evidence was incomplete, and the source was restored.

## Limitations

- Wall-time sample spreads were 86.332% and 91.255%, so host or startup noise may dominate.
- The candidate was slower at the largest input and heap evidence was incomplete; no optimization claim is made.
- No production, cloud, deployment, package installation, paid model, or secret operation was used.

## Public product links

- [CodeVetter](https://codevetter.com/)
- [Download](https://codevetter.com/download)
- [Documentation](https://codevetter.com/docs/)
- [Source](https://github.com/Codevetter/codevetter)