[FEAT] Add performance benchmarking and profiling infrastructure
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- github-actions, python
- Área
- ci-cd, performance, testing, tooling
Línea de trabajo
Comienza revisando los programas existentes en integration/data/prove-rs/, pyk/testing/_profiler.py, kmir.py, smir.py y la configuración de Docker en test.yml. Sigue cómo están organizados los tests de integración de pytest y el Makefile antes de decidir cómo encajan entre sí los puntos de entrada de benchmarking y profiling. Se considerará terminado cuando se cumplan los criterios de aceptación indicados, incluidos los artefactos de benchmark, los resúmenes de CI, la salida de profiling y la documentación en docs/dev/.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Motivation
As the MIR semantics grows in complexity and test coverage expands (see #964), there is no systematic way to detect performance regressions or identify bottlenecks in symbolic execution. Issue #655 shows that performance problems have already surfaced (slow use functions), but we lack the tooling to investigate them systematically or to catch regressions automatically.
Proposed Feature
1. Benchmark Suite
Define a curated set of prove-rs test cases as a benchmark suite — a subset of the existing integration/data/prove-rs/ programs chosen to cover representative workloads (arithmetic, branching, enums, closures, iterators, etc.).
Each benchmark would record:
- Wall-clock time for
kmir prove-rs - Number of proof steps / rewrite rule applications (via K's
--statisticsoutput) - Peak memory usage
Results are stored as a JSON artifact (e.g., bench-results.json) committed or uploaded as a workflow artifact for comparison.
2. Python-level Profiling via pyk.testing.Profiler
pyk already ships a cProfile-based Profiler class (pyk/testing/_profiler.py). We can integrate it into the pytest integration-test runner to generate .prof files for selected tests, enabling:
- Identification of hot Python functions in the SMIR→K transformation pipeline (
kmir.py,smir.py) - Easy investigation of issues like #655 without manual instrumentation
A --profile pytest option (or a dedicated make profile-integration target) would enable this on demand.
3. GitHub Actions Workflow: benchmark.yml
A new workflow triggered on:
pushtomaster— baseline trackingworkflow_dispatch— on-demand profiling for PRs under investigation- Optionally:
pull_requestwith a label likeperfto gate on demand
Steps:
- Build
stable-mir-json+kmir(reuse Docker setup fromtest.yml) - Run the benchmark suite, capturing timing/step counts
- Upload
bench-results.jsonas a workflow artifact - On
masterpush: compare against the previous baseline stored in a GitHub Actions cache and post a summary to the job summary ($GITHUB_STEP_SUMMARY) - Optionally: use
benchmark-action/github-action-benchmarkto track trends over time and comment on PRs when a regression threshold is exceeded
4. make benchmark Target
A local Makefile target for developers to run the benchmark suite locally and view a summary, mirroring CI behaviour.
Acceptance Criteria
- Benchmark suite defined (list of representative test cases with expected step counts)
-
make benchmarktarget runs locally and outputs a timing/step-count table -
--profilemode generates.proffiles for pytest integration tests usingpyk.testing.Profiler -
benchmark.ymlGitHub Actions workflow uploads benchmark artifacts on everymasterpush - CI posts a step-summary table comparing current vs. baseline results
- Documentation added to
docs/dev/on how to run benchmarks and interpret results
Related
- #655 — slow
usefunctions investigation - #964 — external test suite integration (benchmark suite could overlap)
pyk/testing/_profiler.py— existing profiler infrastructure available in thepykdependency
- Lenguaje dominante
- Python
- Estrellas
- 52
- Forks
- 5
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de runtimeverification/mir-semantics
-
Remove #init function from KAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 52/100
runtimeverification/mir-semantics#1078 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
runtimeverification/mir-semantics#1070 · 2 comentarios ·
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
runtimeverification/mir-semantics#1067 ·
-
area:semantics kind:refactor priority:p1 status:triage type:task
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
runtimeverification/mir-semantics#1011 · 1 comentario ·
Todos los issues de runtimeverification/mir-semantics
Issues similares
-
bug server
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
sportsdataverse/sportsdataverse-py#641 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
googleapis/google-cloud-python#18532 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día