-
-
Notifications
You must be signed in to change notification settings - Fork 203
Conversation
uv venv instead of python venv (削除ここまで)uv venv instead of python -m venv (追記ここまで)
uv venv instead of python -m venv (削除ここまで)uv venv and uv pip (追記ここまで)
This reverts commit 4b5f47a.
@corona10
corona10
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since pyperformance users include not only CPython but also alternative implementations, I don’t think relying on uv would be a good approach for us to take. cc @hugovk
Since pyperformance users include not only CPython but also alternative implementations, I don’t think relying on uv would be a good approach for us to take. cc @hugovk
uv supports CPython, PyPy, GraalPy and Pyodidie
--python accepts binaries, eg custom PyPy3 build:
10:36:09.653252000AM CET maurycy@gimel /Users/maurycy/src/pyperformance % uv run --isolated --project=benchmarks/bm_sympy --python=`which pypy3` benchmarks/bm_sympy/run_benchmark.py
Built psutil==7.1.2
Installed 4 packages in 68ms
.......
sympy_expand: Mean +- std dev: 73.9 ms +- 6.0 ms
.......
sympy_integrate: Mean +- std dev: 22.5 ms +- 3.8 ms
.......
sympy_sum: Mean +- std dev: 46.7 ms +- 6.6 ms
.......
sympy_str: Mean +- std dev: 51.1 ms +- 11.6 ms
(削除) If I understand correctly, the only requirement is that -I, -B and -C needs to be supported by an interpreter. I might be totaly wrong here, though. (削除ここまで)uv seems to check sys.implementation.name and match it
No there are a lot of implementations over you listed. e.g RustPython Jython gpython. Let s not make a big huddle to them.
Unless you have a strong motivation to maintain this project based on uv, let's keep it as is based on standard(pip).
I love uv but this should consider other factors.
Fidget-Spinner
commented
Dec 5, 2025
No there are a lot of implementations over you listed. e.g RustPython Jython gpython. Let s not make a big huddle to them.
That doesn't matter. Not to diss the other implementations, but they most likely can't even run pip. If you can't even run pip, there's no point supporting these.
- RustPython can't run pip Tracking pip support in RustPython RustPython/RustPython#5332
- Jython only supports Python 2.7, which clearly can't use pyperformance.
- GPython says
gpython does not include many python modules as many of the core modules are written in C not python. So that's also not gonna work.
There's a reason to not switch to uv by default though --- that would be a breaking change of pyperformance likely requiring a major version bump.
@maurycy I think this is really great work and I would be willing to accept this PR if the default stayed pip, but you allow an option/command line flag to switch to uv. Then I think @corona10's concerns should be solved.
Fidget-Spinner
commented
Dec 5, 2025
FWIW, starting a pip subprocess is extremely slow on other implementations like GraalPy. Even on CPython it is slow. Running a benchmarking run on GraalPy might be faster if we switch to uv, so I'm very much looking forward to this change.
@maurycy I think this is really great work and I would be willing to accept this PR if the default stayed pip, but you allow an option/command line flag to switch to uv. Then I think @corona10's concerns should be solved.
It will be fine with switching to uv as an optional feature as Ken Jin commented.
RustPython can't run pip RustPython/RustPython#5332
For clarity, they can run old pip but fail with the latest pip; anyway, they have a chance to run pyperformance using old pip.
RustPython/RustPython#5332 (comment)
so switching to uv by default will be a big hurdle for new challengers :)
* main: Bump mypy from 1.19 to 1.19.1 (python#448) Add a YAML-parsing benchmark (python#342) Add FastAPI HTTP request benchmark (python#440) Add option for rigorous in benchmark.conf.sample (python#446) Do not `venv.ensure_reqs` twice (python#432) Bump mypy from 1.18.2 to 1.19.0 (python#442) Bump actions/checkout from 5 to 6 in the actions group (python#441) Add example scripts to run pyperformance on a generic host (python#436) Prepare for 1.13.0 release (python#435) Reenable xdsl (python#433) Bump actions/setup-python from 5 to 6 (python#429) Group Dependabot updates for GitHub Actions into single PR (python#431) Bump actions/checkout from 4 to 5 (python#430)
* main: Replace pre-commit with prek in CI and add cooldown to Dependabot (python#452) Add bm_base64 covering common base64 module APIs (python#447)
Uh oh!
There was an error while loading. Please reload this page.
This is a conversation starter now: should we gradually start moving towards
uvthat handles custom builds, venvs and pinned runs more efficiently?The code already works, confirmed with:
Tests are 2x faster:
I didn't want to do too many changes at once, but in my opinion the best direction would be iterating over each benchmark with
uv.pyperformanceis just a benchmark suite after all, and the whole venv, custom build etc. management makes it unnecessarily complex.Notably,
uv runhas --project, --isolated (now it's isolated if the requirements cannot be met), --with-requirements and --python (supporting custom builds), eg:This is similar to what happens now, just merging temporary outputs.
From what I measured venv management and dependencies only take ~5% of the
runtime, so no dramatic speed up should be expected, but the simplification might be worth it. Important to keep in mind that many features are never ever used, if a large chunk of benchmarks stays broken for so long and some obvious issues lurked for a while.Another elephant in the room is compile that could also be outsourced.
I'm more than open to any suggestions!