Problem
We have no repeatable way to measure subgraph size and indexing performance. That means we cannot tell whether a change improves or regresses performance, or by how much. This matters most right now for the cumulative factor stake and earnings feature (#238, PR #217), where we want confidence it is implemented efficiently before merging. As the subgraph grows with new data, indexing cost and size need to be guarded continuously.
Proposed solution
Add tooling, runnable both locally and in CI, that measures:
- Subgraph manifest and build size, and entity counts
- Indexing and sync performance against a fixed block range
- Per mapping or per handler cost where feasible
Surface the results in CI on pull requests so size and performance deltas are visible before merge, and capture a baseline on the current subgraph for comparison.
Scope
- Local script to measure size and indexing performance against a fixed range
- CI workflow that runs the measurement on pull requests and reports the delta
- A baseline captured on the current subgraph
Out of scope
Why now
This gates merging the stake and earnings indexing feature (#238, PR #217) with confidence that it is efficient, and it lets us verify the pre feature performance improvements tracked in #179.
Related
Problem
We have no repeatable way to measure subgraph size and indexing performance. That means we cannot tell whether a change improves or regresses performance, or by how much. This matters most right now for the cumulative factor stake and earnings feature (#238, PR #217), where we want confidence it is implemented efficiently before merging. As the subgraph grows with new data, indexing cost and size need to be guarded continuously.
Proposed solution
Add tooling, runnable both locally and in CI, that measures:
Surface the results in CI on pull requests so size and performance deltas are visible before merge, and capture a baseline on the current subgraph for comparison.
Scope
Out of scope
Why now
This gates merging the stake and earnings indexing feature (#238, PR #217) with confidence that it is efficient, and it lets us verify the pre feature performance improvements tracked in #179.
Related