Preview: less waiting for notes and large-library work
Measured gains in Notes, focused Graph, search rebuilds, and exports, with the limits stated alongside the numbers.
The performance work in Arivu’s open PR stack reduces repeated database reads. It does not change the results to make a benchmark faster. The optimization passes kept ordering, limits, owned data boundaries, and response contents. The later feature-simplification pass is a separate product change.
These changes are not yet in the installer release. The figures below are local measurements, not a promise about every deployment or every request.
Where waiting fell
Authenticated local HTTP checks used matching test databases with 5,000 notes and bookmarks, links, feedback, and legacy planning records. Each endpoint had 25 samples after warmup:
| Request | Median before | Median after | Less time |
|---|---|---|---|
| Notes | 168.94 ms | 75.27 ms | 55% |
| Focused Graph | 13.22 ms | 3.09 ms | 77% |
Ten concurrent rounds of Notes, Search, and recent Graph completed in a median 471.76 ms before and 313.66 ms after, about 34% less time. Search and recent Graph did not improve in that run. Do not read the table as an app-wide gain.
Large-library operations
In the earlier batching pass, a 10,000-bookmark fixture with linked notes took 54.73 seconds to rebuild search before the change and 0.521 seconds after. Full export went from 28.66 seconds to 2.615 seconds. These are medians of three single-operation samples, with setup outside the timer.
The final source-learning preview was checked again on September 28: search rebuild took a median 0.437 seconds and export 2.215 seconds on the same fixture. That repeat confirms the fast path still runs; it is not a fresh matched before-and-after comparison.
The fixture uses short text. Large documents, real vectors, disk speed, and concurrent work will change the result. Provider response time is outside these measurements; they say nothing about how quickly a hosted model answers.
What we are not claiming
There is no universal 30% speedup. Nor did batching alone cut production code by 20%: its first pass removed only 12 physical production lines. Removing low-value tests is not a production-code reduction. The separate simplification pass removes features because they do not fit the product’s purpose, not to meet a line-count target.
See the benchmark report and reproduction commands for fixtures, response comparisons, and limits. Measure your own workload before planning capacity around these figures.