matrixorigin / matrixorigin/matrixone
[Performance]: Reduce PR test latency without losing vector and Arrow coverage
- Dominant language
- Go
- Stars
- 1.9k
- Forks
- 311
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 768
Description
- [x] I have checked the existing issues.
## Environment
- Version or commit-id: Comparable successful MatrixOne CI run `0c62d664d56f5bd837c08ec789faa5266d4a7a3b`; reference run [34807757226](https://github.com/matrixorigin/matrixone/actions/runs/34807757226/job/103862888965?pr=28833).
- Hardware parameters: GitHub Actions runner; exact CPU/GPU runner parameters were not recorded in the reference report and must be captured for the CUDA A/B run.
- OS type: GitHub Actions CI environment; exact image was not recorded in the reference report.
- Others: MatrixOne PR CI UT/BVT path. The issue is about reducing feedback latency while preserving the existing test coverage and result oracles.
## Details of Performance
The PR CI UT path has a long tail: a comparable successful run took about 46 minutes. Several GPU vector cases hold the device with a fixed `SELECT SLEEP(30)`, and Arrow gate tests start separate embedded clusters. These waits increase PR feedback time without adding coverage.
The desired outcome is to replace unnecessary fixed waits with bounded, observable readiness checks while keeping the same scenarios, final assertions, retry behavior, and result oracles. The change must not add skip or short paths, move cases to external or nightly regression, or reduce coverage.
## Proposed fix
- Replace the fixed sleep in the 10 async/load/delete/sharded-delete GPU vector cases with bounded `@wait_expect` readiness gates.
- Keep every original final vector query and `.result` oracle.
- Reuse the Arrow rollout fixture for compatible gate-disabled and distributed-disabled fallback checks.
- Keep restore, global-metric, boundary-data, transaction-order, scheduler-state, and restart-sensitive UT cases isolated.
## Frequency scope
“Top10” means the ten slowest cases in the comparable UT run. All Top10 scenarios remain in the MatrixOne UT/GPU case system. `UT_SHARD` remains execution grouping only; this change adds no skip or short path and moves no case to external or nightly regression. Frequency is used only to prioritize safe in-place optimization.
## Coverage and acceptance
- All 10 GPU cases retain their original 48 final vector probes and result oracles; multi-phase DDL and snapshot waits remain unchanged.
- Arrow rollout, disabled-gate, distributed-fallback, rollback atomicity, and roll-forward scenarios still execute.
- `gofmt`, `git diff --check`, and the Arrow rollout race test pass.
- Measure wall time, GPU occupancy, and failure rate on the same CUDA runner before and after the change.
- For the current GPU-only PR #28872, also record normal-result comparison, teardown, same-instance reruns, and the CN topology used for the CUDA run.
## Additional information
- Current PR: [#28872](https://github.com/matrixorigin/matrixone/pull/28872), which handles the GPU-vector portion of this issue.
- The current PR candidate is based on `main` and uses bounded CDC/storage-tail and vector-readiness gates.
- CUDA A/B measurement remains to be run on the Y7000P or another x86_64 NVIDIA host. No local macOS result is presented as GPU evidence.
- External regression wiring is future-only and is outside this fix.
Contributor guide
Assessment
This issue has not been assessed yet.