Hacker News Reader

Comment by CivBase | Hacker News Reader

A 10% reduction in cache size in exchange for a 4% slowdown doesn't seem obviously worthwhile to me, especially when it comes at an increase in complexity.

View on HN

Percentages aren't always the right gauge. uv isn't something I run frequently or for long periods of time. It's like a couple seconds every month or whatever. I would rather spend an extra second waiting every year to have hundreds more megabytes all the time.

When actively developing Python projects, running uv a dozen times per hour isn't unusual. Those seconds add up fast. Whereas freed disk space remains unused.

warm cache case is only imperceptibly slower, no?

True, haven't read the source and only went by what the other commenter said. But one could argue 500MB more free space is similarly imperceptible.

There are still many environments with <=250GB, below that I wouldn't call it negligible. And let's not forget that the price per GB has appreciated a LOT!

They're likely the same environments that can't keep warm cache in memory, so the performance penalties are higher too.

You could reverse the last sentence to "freed disk space reduces the need to clean the hd". And I don't even mean physical limitation as much as the compulsion to manually clean ballooning cache dirs once in a while.

Overprovisioning also reduces the need to clean the disk. I've had a terabyte Macbook for over a year, developing in 7 different tech stacks simultaneously, never cleaning anything up manually, and I still have over 60% space left.

It's a tradeoff between wasting a little time everyday vs. wasting equally little time every year or so but also having the mental load of cleaning up plus maybe existential dread vs. spending more money to never have either problem. I do understand the last one isn't an option for everyone, but if it is, it's absolutely worth it.

Whereas I made a mistake and bought an underspeced MacBook and my 512GB disk is constantly on the brink of full as I reclaim the last 40 GB over and over from different caches, downloads, and wherever else and had to simply give up on several projects because of their disk usage.

Disk isn't free, especially now.

Exactly my experience, even worse because for me it's 2x256GB drives. Eventually I bit the bullet and upgraded one of them to 1TB, but not the one my root partition is mounted on (too lazy for that), so now I find myself moving various large directories across to my "extra" drive and symlinking them. Funnily enough I don't remember this ever being a problem back when 50GB was considered a lot.

Because when 50gb was a lot, by the time you filled it, 200 GB was cheap and a non event.

Yea, I remember when the family computer had a 40MB hard drive and it was never ever filled to capacity. Now I’m wondering how many new disks to add to my ZFS pool, and when. And how to budget for it.

We upgraded our 40MB harddrive to a 210MB, as it was constantly getting filled up. I was wondering what on earth to do with all this space, it seemed limitless.

A week later I was cleaning up disk space again...

I don't disagree. But if you're in that position, surely you'd be better off emptying the cache and disabling it?

The things which use my disk are things like package caches in several languages, build artifacts in both release and debug, multiplied by worktrees, things like iOS device support and release files + simulators, docker containers and related.

I had to give up on things like Lean theorem prover projects and VM projects because the disk space wasn't there.

The causes of disk waste are manifold and usually can't just be disabled and even when they can the result is constant rebuilding, redownloading, etc.

Too many developer products act like disk and memory is free to waste and the consequences have gotten ridiculous.

Making things faster is much easier than making things smaller. I'm sure we can win back a 4% slowdown elsewhere since we have so many more levers to pull from.

Yeah, my bigger worry here is more about if somebody direct edits a file in their venv and uv was unable to make the venv with reflink/COW semantics and fell back to hardlinks.

This could happen with a user asking their editor to show definition, and then not realizing the result was in some other package, changing it, and saving it, but only if the editor's normal atomic replace mode is disabled. So perhaps that sounds farfetched. But if an AI agent wants to patch some package in a venv, I've seen them bypass the editor and use command line tools to make edits often enough to be concerned. Like corrupting the cache for one package version is already not ideal, and this could potentially affect multiple versions now?

I suppose is this happens the right fix is to nuke the cache completely?

>especially when it comes at an increase in complexity.

Or (nasty) bugs hard to debug

Reply on news.ycombinator.com