Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How uv got so fast

nesbitt.io

Post reply on HN
Print view View original

391–400 of 468 posts

Re: How uv got so fast

#391

Post by zahlman »

BiteCode_dev wrote: post #283
zahlman wrote: post #263

Earlier quoted context omitted.

> uncompressing packages while they are still being downloaded ... but the archive directory is at the end of the file? > no python VM startup overhead This is about 20 milliseconds on my 11-year-old hardware.

HTTP range strikes again. As for 20 ms, if you deal with 20 dependencies in parallel, that's 400ms just to start working. Shaving half a second on many things make things fast. Althought as we saw with zeeek in the other comment, you likely don't need multiprocessing since the network stack and unzip in the stdlib release the gil. Threads are cheaper. Maybe if you'd bundle pubgrub as a compiled extension, you coukd g…

Why are you starting a separate Python process for each dependency?

Re: How uv got so fast

#392

Post by zahlman »

CamouflagedKiwi wrote: post #361
zahlman wrote: post #241

Earlier quoted context omitted.

> the entire python ecosystem generally does not put much emphasis on startup time. You'd think PyPy would be more popular, then. > even modules in the standard library will pre-compile regular expressions at import time, even if they're never used, like the "email" module. Hmm, that is slower than I realized (although still just a fraction of typical module import time): $ python -m timeit --setup 'import re' 're.co…

> You'd think PyPy would be more popular, then. PyPy doesn't do anything to help startup time. In fact, it's typically a bit slower to start up than CPython. You reap the speed benefits from PyPy once it's been running for a little while and it can JIT compile the hot bits of code.

> PyPy doesn't do anything to help startup time. In fact, it's typically a bit slower to start up than CPython.

Considerably slower on my machine. Yes, that was my point. If the community doesn't care about startup time, you'd expect more adoption of an implementation that sacrifices that startup time for later performance.

Re: How uv got so fast

#393

Post by zahlman »

collinmanderson wrote: post #346
zahlman wrote: post #241

Earlier quoted context omitted.

> the entire python ecosystem generally does not put much emphasis on startup time. You'd think PyPy would be more popular, then. > even modules in the standard library will pre-compile regular expressions at import time, even if they're never used, like the "email" module. Hmm, that is slower than I realized (although still just a fraction of typical module import time): $ python -m timeit --setup 'import re' 're.co…

> I agree the email module is atrocious in general Hah. Yes sounds like we are very much on the same page here. Python stdlib could really use a simple generic email/http header parser. > It's unusual that you actually need to install Python again after initially having "python+dependencies installed". I’m thinking about 3rd party installers like poetry, pip-tools, pdm, etc, where your installer needs python+dependen…

> Do you have anything public yet?

The repo is https://github.com/zahlman/paper but it's not really usable and it's missing a bunch of local very unfinished stuff (and my README template definitely needs fixing). More of a "watch this space" but I would really like to push out a Show HN for the first chunk of functionality soon.

Re: How uv got so fast

#394

Post by firesteelrain »

rmah wrote: post #365
firesteelrain wrote: post #287

Earlier quoted context omitted.

Why not just use a Python container rather than rely on having the latest binary installed on the system? Then venv inside the container. That would get you the “venv of a version” that you are referring to

Our firm uses python extensively and the virtual environment for every script or script is ... difficult. We have dozens of python scripts running for team research and in production, from small maintenance tools to rather complex daemons. Add to that the hundreds of Jupyter notebooks used by various people. Some have a handful of dependencies, some dozens of dependencies. While most of those scripts/notebooks are on…

But in your case if you had a vanilla even just a standard, hardened RHEL image then you can run as many container variations as you want and not be impacted by host changes. Actually the host can stay pretty static.

You would have a standard container image

Re: How uv got so fast

#395

Post by zahlman »

jacquesm wrote: post #330
zahlman wrote: post #265

Earlier quoted context omitted.

Scenarios like that are simply not realistic. Besides which, multiple solutions exist for bundling Python with an application.

Scenarios like that occur daily. I do quite a bit of software development and whenever I come across something that really needs python I mentally prepare for a day of battle with the various (all subtly broken) package managers, dependency hell and circular nonsense to the point that I am also ready to give up on it after a day of trying. Just recently: a build of a piece of software that itself wasn't written in py…

> Scenarios like that occur daily. I do quite a bit of software development and whenever I come across something that really needs python I mentally prepare for a day of battle with the various (all subtly broken) package managers, dependency hell and circular nonsense to the point that I am also ready to give up on it after a day of trying.

Please name a set of common packages that causes this problem reliably.

Re: How uv got so fast

#396

Post by [deleted] »

eru wrote: post #170
Nextgrid wrote: post #158

Earlier quoted context omitted.

It's not just greenfield-ness but the fact it's a commercial endeavor (even if the code is open-source). Building a commercial product means you pay money (or something they equally value) to people to do your bidding. You don't have to worry about politics, licensing, and all the usual FOSS-related drama. You pay them to set their opinions aside and build what you want, not what they want (and if that doesn't work,…

> You don't have to worry about politics, licensing, and all the usual FOSS-related drama. You pay them to set their opinions aside and build what you want, not what they want (and if that doesn't work, it just means you need to offer more money). Money is indeed a great lubricator. However, it's not black-and-white: office politics is a long standing term for a reason.

[deleted]

Re: How uv got so fast

#397

Post by tjwebbnorfolk »

Nextgrid wrote: post #174
eru wrote: post #170

Earlier quoted context omitted.

> You don't have to worry about politics, licensing, and all the usual FOSS-related drama. You pay them to set their opinions aside and build what you want, not what they want (and if that doesn't work, it just means you need to offer more money). Money is indeed a great lubricator. However, it's not black-and-white: office politics is a long standing term for a reason.

Office politics happen when people determine they can get more money by engaging in politics instead of working. This is just an indicator people aren't being paid enough money (since people politicking around is detrimental to the company, it is better off paying them whatever it takes for them not to engage in such behavior). "You get what you pay for" applies yet again.

Figuring out how to allocate scarce career resources at a company ("impact", recognition, promotions, etc) is fundamental to the job of getting stuff done in a large organization.

There's an old saying: politics began when two people in a cave found themselves with only one blanket.

Re: How uv got so fast

#398

Post by zahlman »

oefrha wrote: post #304
zahlman wrote: post #268

Earlier quoted context omitted.

> Linux systems commonly already provide an outdated system Python you don’t want to use Even with LTS Ubuntu updated only at EOL, Python will not be EOL most of the time. > A single Python version for the entire system fundamentally doesn’t work for many people thanks to shitty compat story in the vast ecosystem. My experience has been radically different. Everyone is trying their hardest to provide wheels for a wid…

For much of the ML/scientific ecosystem, you're lucky to get all your deps working with the latest minor version of Python six months to a year after its release. Random ML projects with hundreds to thousands of stars on GitHub may only work with a specific, rather ancient version of Python. > Because otherwise this problem is trivially solved by anyone competent. In particular, building and installing Python from so…

> Random ML projects with hundreds to thousands of stars on GitHub may only work with a specific, rather ancient version of Python.

Can you name some?

> Do you compile your GCC every time before you compile your Python? Why not? It Just Works.

If I needed a different version of GCC to make Python work, then probably, yes. But I haven't yet.

Just like I barely ever need a different version of Python. I keep several mainly so that I can test/verify compatibility of my own code.

Re: How uv got so fast

#399

Post by zahlman »

IshKebab wrote: post #285
zahlman wrote: post #126

Earlier quoted context omitted.

> Not many projects use setup.py now anyway and pip is still super slow. Yes, but that's still largely not because of being written in Python. The architecture is really just that bad. Any run of pip that touches the network will end up importing more than 500 modules and a lot of that code will simply not be used. For example, one of the major dependencies is Rich, which includes things like a 3600-entry mapping of…

> Any run of pip that touches the network will end up importing more than 500 modules and a lot of that code will simply not be used. That's a property of Python though. The fact that it isn't compiled (and that importing is very slow). > a 3600-entry mapping of string names to emoji Which can easily be zero-cost in Rust. > It literally doesn't know how to access its own package download cache without hitting the net…

> That's a property of Python though. The fact that it isn't compiled (and that importing is very slow).

Bytecode compilation is compilation.

There are many things that could be used to improve import speed that I never even see discussed, let alone implemented.

But most importantly, pip doesn't need to have all these modules imported. They already proved they could defer the Requests imports; but the actual network calls aren't that hard to do with the standard library anyway. (As nice as it would be to have Requests in the standard library, but I digress.) Most of the stuff it imports up-front from Rich will go entirely unused.

> Which can easily be zero-cost in Rust.

Which is irrelevant to the point.

> This is the only example you've given that actually fits with your thesis.

No. My thesis is that pip doesn't have to be the way it is in order to actually solve the problem of installing Python packages. Everything I mentioned is an example of a thing pip doesn't have to do in order to install packages, and slows it down unnecessarily.

Re: How uv got so fast

#400

Post by firesteelrain »

baby_souffle wrote: post #377
firesteelrain wrote: post #287

Earlier quoted context omitted.

Why not just use a Python container rather than rely on having the latest binary installed on the system? Then venv inside the container. That would get you the “venv of a version” that you are referring to

> Why not just use a Python container rather than rely on having the latest binary installed on the system? Sometimes this is the right answer. Sometimes docker/podman/runc are not an option nor would the headache of volumes/mounts/permissions/hw-pass-through be worth the additional mess. It is hard to over-state how delightful putting `uv` in the shebang is: in `demo.py`: #!/usr/bin/env -S uv run # /// script # requ…

Yes, PATH-driven interpreter selection is the source of the detours. uv eliminates interpreter ambiguity but requires uv as a prerequisite. This improves portability inside environments that standardize uv; it’s not “portable to machines with nothing installed.”

Though, this isn’t about avoiding installs; it’s about making the one install (uv) the only thing you have to get right, instead of debugging whatever python means today.

I was advocating for containers as the “hard isolation / full stack” solution which eliminate host interpreter ambiguity and OS drift by running everything inside a pinned image. But you do need podman and have the permissions set right on it.

Post reply on HN