Hacker News Reader

Hacker News

Comment by BiteCode_dev | Hacker News Reader

Full thread

BiteCode_dev

Other design decisions that made uv fast:

- uncompressing packages while they are still being downloaded, in memory, so that you only have to write to disk once

- design of its own locking format for speed

But yes, rust is actually making it faster because:

- real threads, no need for multi-processing

- no python VM startup overhead

- the dep resolution algo is exactly the type of workload that is faster in a compiled language

Source, this interview with Charlie Marsh: https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-th...

The guy has a lot of interesting things to say.

View on HN

> real threads, no need for multi-processing

parallel downloads don't need multi-processing since this is an IO bound usecase. asyncio or GIL-threads (which unblock on IO) would be perfectly fine. native threads will eventually be the default also.

Indeed, but unzipping while downloading do. Analysing multiple metadata files and exporting lock data as well.

Now I believe unzip releases the GIL already so we could already benefit from that and the rest likely don't dominate perfs.

But still, rust software is faster on average than python software.

After all, all those things are possible in python, and yet we haven't seen them all in one package manager before uv.

Maybe the strongest advantage of rust, on top of very clean and fast default behaviors, is that it attracts people that care about speed, safety and correctness. And those devs are more likely to spend time implementing fast software.

Thought the main benefit of uv is not that it's fast. It's very nice, and opens more use cases, but it's not the killer feature.

The killer feature is, being a stand alone executable, it bypasses all python bootstrapping problems.

Again, that could technically be achieved in python, but friction is a strong force.

> Maybe the strongest advantage of rust, on top of very clean and fast default behaviors, is that it attracts people that care about speed, safety and correctness. And those devs are more likely to spend time implementing fast software.

people who have this opinion should use Rust, not Python, at all. if Python code does not have sufficient speed, safety, and correctness for someone, it should not be used. Python's tools should be written in Python.

> The killer feature is, being a stand alone executable, it bypasses all python bootstrapping problems.

I can't speak for windows or macs but on Linux, system pythons are standard, and there is no "bootstrapping problem" using well known utilities that happen to be written in Python.

For the latter point, you are blinded by your own competence.

Bootstrapping a clean python env is the single biggest problem for people that are not daily coding in python.

That's half of the community in the python world.

When you write sqla that's not obvious, because you know a lot. But for the average user, uv was a savior.

I wrote a pretty long article on that here:

https://www.bitecode.dev/p/why-not-tell-people-to-simply-use

We also discuss it with brett cannon there:

https://www.bitecode.dev/p/brett-cannon-on-python-humans-and

But the most convincing argument is to teach python to kids, accountants, mathematicians, java coders and sysadmin.

After 20 years of doing that, I saw the same problems again and again.

And then uv arrived. And they disapeared for those people.

> And then uv arrived. And they disapeared for those people.

I'm not arguing against tools that make things as easy as possible for non programmers, I'm arguing against gigantic forks in the Python installation ecosystem. Forks like these are harmful to the tooling, I'm already suffering quite a bit due to the flake8/ruff forking where ruff made a much better linter engine but didnt feel like implementing plugins, so everyone is stuck on what I feel is a mediocre set of linting tools. Just overall I don't like Astral's style and I think a for-profit startup forking out huge chunks of the Python ecosystem is going to be a bad thing long term.

> 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 get pretty close to uv's perf.

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

Real thread are very recent and didn't exist when uv was created. So you needed multiprocesses.

No, I mean why are you starting them for each dependency, rather than having a few workers pulling build requests from a queue?

At least one worker for each virtual cpu core you get for CPU. I got 16 on my laptop. My servers have much more.

If I have 64 cores, and 20 dependencies, I do want the 20 of them to be uncompressed in parallel. That's faster and if I'm installing something, I wanna prioritize that workload.

But it doesn't have to be 20. Even say 5 with queues, that's 100ms. It adds up.

Using the -S (“isolated”) flag can maybe cut startup in half.

Reply on news.ycombinator.com