5 ms·

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.

by CivBase 17d ago

colechristensen 17d ago
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.
- CivBase 17d ago
  I don't disagree. But if you're in that position, surely you'd be better off emptying the cache and disabling it?
  - colechristensen 17d ago
    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.
- NoboruWataya 17d ago
  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.
  - db48x 16d ago
    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.
    - magicalhippo 16d ago
      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...
  - drfloyd51 16d ago
    Because when 50gb was a lot, by the time you filled it, 200 GB was cheap and a non event.
mococa 17d ago
>especially when it comes at an increase in complexity. Or (nasty) bugs hard to debug
mminer237 17d ago
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.
- Xirdus 16d ago
  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.
  - kekebo 16d ago
    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.
    - Xirdus 16d ago
      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.
  - pas 16d ago
    warm cache case is only imperceptibly slower, no?
    - Xirdus 16d ago
      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.
charliermarsh 16d ago
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.
- jsmith45 16d ago
  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?

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.

by CivBase 17d ago

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.

colechristensen 17d ago

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.

CivBase 17d ago
I don't disagree. But if you're in that position, surely you'd be better off emptying the cache and disabling it?
- colechristensen 17d ago
  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.
NoboruWataya 17d ago
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.
- db48x 16d ago
  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.
  - magicalhippo 16d ago
    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...
- drfloyd51 16d ago
  Because when 50gb was a lot, by the time you filled it, 200 GB was cheap and a non event.

mococa 17d ago

>especially when it comes at an increase in complexity. Or (nasty) bugs hard to debug

mminer237 17d ago

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.

Xirdus 16d ago
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.
- kekebo 16d ago
  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.
  - Xirdus 16d ago
    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.
- pas 16d ago
  warm cache case is only imperceptibly slower, no?
  - Xirdus 16d ago
    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.

charliermarsh 16d ago

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.

jsmith45 16d ago
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?