[codspeed]

This sets up continuous performance measurement with CodSpeed for both halves of MMUX Vite: the Flask backend and the React frontend. Benchmarks run in CPU simulation mode, so results are hardware-independent and every pull request gets a performance report.

What was added

Backend benchmarks (flaskapi/benchmarks/, pytest-codspeed)

29 benchmarks covering the code that runs on the request path of every SuMo / UQ / MOGA interaction:

• test_bench_data_processing.py — variable-name sanitization, load_data for .dat and .csv job collections, process_input_file with log transforms, Pareto-front extraction (get_non_dominated_indices), correlation indices, manual UQ sample generation (1k and 10k samples), grid and along-axes sample generation.
• test_bench_lhs.py — the Latin Hypercube sampler used by POST /flask/sampling/lhs, across all supported methods (classic, center, maximin, centermaximin, correlation, lhsmu) plus a larger design.
• test_bench_preprocessor.py — DataPreprocessor setup/fit, transform (DataFrame and record payloads) and inverse transform.
• test_bench_serialization.py — the camelCase/snake_case conversion helpers on a realistic plot payload, pydantic validation of the SuMo along-axes and cross-validation requests with 300 jobs, response serialization, and a full Flask request/response round trip through register_json_transformers.

The benchmarks live outside tests/ on purpose: the test suite's autouse fixtures (DEBUG logging to disk, environment patching) would otherwise be measured together with the code under test. All inputs are deterministic (fixed seeds and shapes).

Frontend benchmarks (node/bench/, tinybench)

• jobCollectionCsv.bench.ts — parseJobCollectionCsv on 50, 1k and 5k job collections; the upload path parses the whole file on the main thread.
• dakotaRequestKey.bench.ts — buildDakotaRequestKey, rebuilt on every render of the 1D/2D/3D surrogate plots (slider drags).
• sampling.bench.ts — getSamplingStartValue / getSamplingEndValue across 100 input variables with mixed distributions.
• index.ts — entry point that registers every group on one withCodSpeed(new Bench()) suite, run with npm run bench.

Only framework-independent utilities are benchmarked, so no DOM or generated oSPARC client is needed.

CI and tooling

• .github/workflows/codspeed.yml — two jobs (backend and frontend) using CodSpeedHQ/action@v5 in simulation mode on ubuntu-latest, with OIDC authentication. It mirrors the existing CI setup (actions/checkout@v5, astral-sh/setup-uv@v3, Node 24 with npm cache, make install-flaskapi-deps).
• make bench-flaskapi, make bench-node and make bench for local runs.
• npm run bench script in node/package.json.
• CodSpeed badge and a short "Performance benchmarks" section in the README.

Notes

• tinybench instead of vitest bench on the frontend. main recently upgraded Vitest to v5, and @codspeed/vitest-plugin currently supports Vitest ^3.2 || ^4 only (including its 6.0 beta), so the vitest integration cannot be used here. The benchmarks therefore run on tinybench with @codspeed/tinybench-plugin. tinybench is pinned to v5 (^5.1.0): v6 is not supported by the CodSpeed plugin yet — tracking issue: Support tinybench 6.0.0 CodSpeedHQ/codspeed-node#69. When Vitest 5 support lands, these benchmarks can be moved to vitest bench with very little churn (each file already exports a register*Benchmarks function). tsx was added as a dev dependency to execute the TypeScript entry point (node --import tsx bench/index.ts); the CodSpeed runner needs node as the top-level process, which is why the script does not shell out through a separate TS runner binary.
• pytest-codspeed is installed as an overlay (uv run --with 'pytest-codspeed>=5,<6') rather than being added to flaskapi/pyproject.toml. The pinned itis-dakota==1.5.9 only publishes cp311/cp312 wheels, so the uv lock file cannot currently be re-resolved at all (uv lock fails on a clean checkout, independently of this change). Adding a dependency would therefore require touching requires-python or the Dakota pin, which is out of scope here. Once the lock can be resolved again, moving pytest-codspeed into the test dependency group and simplifying the CI command is a one-line follow-up.
• BLAS thread pools are pinned to 1 in flaskapi/benchmarks/conftest.py (before numpy is imported). Under CPU simulation the threads are serialized and OpenBLAS' spin-waiting made the correlation-based LHS benchmark hang for tens of minutes; with the pin the whole backend suite completes in about 75 seconds.

Verification

Both suites were run locally with the CodSpeed CLI in simulation mode (29 backend + 7 frontend benchmarks, all reporting results), ruff check / ruff format and ty check pass on the backend, Prettier passes on the new frontend files, and the existing vitest tests still pass. node/package-lock.json was regenerated with npm (not hand-merged) after merging main.

Next steps

• Merge to main so CodSpeed records a baseline; subsequent pull requests will then show relative changes.
• Extend coverage as needed — the Dakota-driven surrogate workflows (cross-validation, Sobol indices) are not benchmarked because they spawn a real Dakota subprocess.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.97%. Comparing base (4725a8b) to head (cc1c81c).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #623   +/-   ##
=======================================
  Coverage   57.97%   57.97%           
=======================================
  Files         106      106           
  Lines        6436     6436           
  Branches      497      497           
=======================================
  Hits         3731     3731           
  Misses       2643     2643           
  Partials       62       62           

Flag	Coverage Δ
flaskapi	88.56% <ø> (ø)
node	20.70% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[codspeed]

Congrats! CodSpeed is installed 🎉

🆕 29 new benchmarks were detected.

You will start to see performance impacts in the reports once the benchmarks are run from your default branch.

Detected benchmarks

• test_lhs_methods[correlation]: 240.7 ms
• test_compute_correlation_indices: 44.8 ms
• test_create_grid_samples: 460.3 ms
• test_create_manual_uq_samples[1000]: 3.8 ms
• test_create_manual_uq_samples[10000]: 21.9 ms
• test_create_samples_along_axes: 64.7 ms
• test_get_non_dominated_indices: 239 ms
• test_load_data_csv: 39.9 ms
• test_load_data_dat: 23.9 ms
• test_process_input_file_with_log: 348.7 ms
• test_sanitize_varnames_dataframe: 1.8 ms
• test_sanitize_varnames_list: 2.6 ms
• test_lhs_classic: 28.6 ms
• test_lhs_large_design: 290.4 ms
• test_lhs_methods[center]: 9.2 ms
• test_lhs_methods[centermaximin]: 40.4 ms
• test_lhs_methods[lhsmu]: 45.4 ms
• test_lhs_methods[maximin]: 136.4 ms
• test_inverse_transform: 23.9 ms
• test_inverse_transform_ndarray: 22.7 ms
• ...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

---

[JavierGOrdonnez]

Issue: CodSpeed is incompatible with Vitest 5 atm

• @codspeed/vitest-plugin 5.7.1 was released on June 24, 2026
• Vitest 5 was released on September 3, 2026

CodSpeed’s Vitest 5 work is tracked in PR #86, opened June 29, 2026. It remains open and draft, last updated September 22, 2026. No public ETA. Monitor.