Comment by dboreham

1 day ago

I've been doing software of all kinds for a long long time. I've never, ever, been in a position where I was concerned about the speed of my package manager.

Compiler, yes. Linker, sure. Package downloader. No.

21 comments

dboreham

Reply
m00x  21 hours ago

When you're in a big company, the problem really starts showing. A service can have 100+ dependencies, many in private repos, and once you start adding and modifying dependencies, it has to figure out how to version it to create the lock file across all of these and it can be really slow.

Cloud dev environments can also take several minutes to set up.

travisd  1 day ago

Many of these package managers get invoked countless times per day (e.g., in CI to prepare an environment and run tests, while spinning up new dev/AI agent environments, etc).

  • zingar  21 hours ago

    Is the package manager a significant amount of time compared to setting up containers, running tests etc? (Genuine question, I’m on holiday and can’t look up real stats for myself right now)

    • maxbond  21 hours ago

      Anecdotally unless I'm doing something really dumb in my Dockerfile (recently I found a recursive `chown` that was taking 20m+ to finish, grr) installing dependencies is longest step of the build. It's also the most failure prone (due to transient network issues).

  • byroot  21 hours ago

    Ye,s but if your CI isn't terrible, you have the dependencies cached, so that subsequent runs are almost instant, and more importantly, you don't have a hard dependency on a third party service.

    The reason for speeding up bundler isn't CI, it's newcomer experience. `bundle install` is the overwhelming majority of the duration of `rails new`.

    • maccard  21 hours ago

      > Ye,s but if your CI isn't terrible, you have the dependencies cached, so that subsequent runs are almost instant, and more importantly, you don't have a hard dependency on a third party service.

      I’d wager the majority of CI usage fits your bill of “terrible”. No provider provides OOTB caching in my experience, and I’ve worked with multiple in house providers, Jenkins, teamcity, GHA, buildkite.

      7 replies →

maccard  21 hours ago

There is no situation where toolchain improvements or workflow improvements should be snuffed at.

  • mikepurvis  21 hours ago

    It can be harder to justify in private tooling where you might only have a few dozen or hundred devs saving those seconds per each invocation.

    But in public tooling, where the benefit is across tens of thousands or more? It's basically always worth it.

    • maccard  20 hours ago

      Obviously effort vs reward comes in here, but if you have 20 devs and you save 5 seconds per run, you save a context switch on every tool invocation possibly.

      1 reply →

skinnymuch  21 hours ago

I agree for my own projects where the code and libraries are not enormous. The speed and size gains aren’t going to be something that matters enough.