3 ms·

It wants to update a few times a day by default when you call it, so running a simple brew install anything normally takes about 30 seconds (I'm in a MB Pro), e

by ratww 6y ago

It wants to update a few times a day by default when you call it, so running a simple brew install anything normally takes about 30 seconds (I'm in a MB Pro), even if it's just to say the package you want wasn't found. If you don't run it daily, it takes about a minute or two to update. But even when it doesn't update, it is extremely slow compared to any other package managers. It is disruptively slow and it takes a lot of resources, even in a powerful machine (and I'm not talking about compilation here).

tokamak-teapot 6y ago
I think I’m just not used to faster package managers and I don’t install packages often enough for it to feel disruptive to wait a few seconds. I do like tools to be as fast as possible, though, and I’d forgotten about that update it does sometimes when I run it - that does seem to take a long time. I’ll have a look at how it works and see what the things are that take time. I would expect network traffic for updates, perhaps whatever it’s getting updates from does some processing (I’m sure it said something about GitHub), perhaps there is some dependency resolution that needs CPU... It would be interesting to compare its architecture to other package managers if they’re significantly faster.
- ratww 6y ago
  The slowness is mostly due to Ruby and the git pull. I contributed in the past and reimplemented it in bash, and there isn't much going on, honestly. 99% of the time, installing a package consists of downloading a few zips from their CDN, decompressing and linking. For those cases Brew could just be checking an API instead of constantly cloning the git repository. I'm quite surprised nobody has reimplemented it in Rust or Go. The architecture is quite simple compared to a normal package manager. Maybe it's just superstition: people see "package manager" and assume it's complicated instead of digging into the code and finding out how it works.

by ratww 6y ago

tokamak-teapot 6y ago

I think I’m just not used to faster package managers and I don’t install packages often enough for it to feel disruptive to wait a few seconds. I do like tools to be as fast as possible, though, and I’d forgotten about that update it does sometimes when I run it - that does seem to take a long time. I’ll have a look at how it works and see what the things are that take time. I would expect network traffic for updates, perhaps whatever it’s getting updates from does some processing (I’m sure it said something about GitHub), perhaps there is some dependency resolution that needs CPU... It would be interesting to compare its architecture to other package managers if they’re significantly faster.

ratww 6y ago
The slowness is mostly due to Ruby and the git pull. I contributed in the past and reimplemented it in bash, and there isn't much going on, honestly. 99% of the time, installing a package consists of downloading a few zips from their CDN, decompressing and linking. For those cases Brew could just be checking an API instead of constantly cloning the git repository. I'm quite surprised nobody has reimplemented it in Rust or Go. The architecture is quite simple compared to a normal package manager. Maybe it's just superstition: people see "package manager" and assume it's complicated instead of digging into the code and finding out how it works.