| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
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 |
Sorry, something went wrong.
|
No there are a lot of implementations over you listed. e.g RustPython Jython gpython. Let s not make a big huddle to them. |
Sorry, something went wrong.
|
Unless you have a strong motivation to maintain this project based on uv, let's keep it as is based on standard(pip). |
Sorry, something went wrong.
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.
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
It will be fine with switching to uv as an optional feature as Ken Jin commented.
For clarity, they can run old pip but fail with the latest pip; anyway, they have a chance to run pyperformance using old pip. |
Sorry, something went wrong.
* 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)
| Back | FazBrowse Home | New Git URL |
This is a conversation starter now: should we gradually start moving towards uv that 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. pyperformance is just a benchmark suite after all, and the whole venv, custom build etc. management makes it unnecessarily complex.
Notably, uv run has --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 run time, 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!