Always show install times during bundle install #9153
Conversation
I'd like to suggest that we display the recently-added "Installed in" and
"Downloaded in" outputs by default, rather than only when DEBUG=true.
It's very common to:
- Run bundle install during deploys or CI
- Have `--jobs` > 1
- Have some gems take a very long time to install. E.g. ones with native extensions.
When `--jobs` > 1, it's impossible to tell which gems are slow, unless "Installed In"
is displayed.
DEBUG=true is **very** verbose, and seems like too much for this common need.
This feels like a common enough case to output the new timings by default.
Or, if we don't want to enable it by default, would we be ok with adding an
`--timing` option, to allow outputing even when `DEBUG=true` is not set?
i.e. like:
```ruby
if Bundler.settings[:timing]
Bundler.ui.confirm "Installed #{spec.name} in: #{format("%.3f", Time.now - start_time)}s"
end
```
?
|
I like the idea of a |
|
👍 Shall I go ahead and update the PR with that? |
|
I'm not sure what is useful for all users. I know stats is important to maintain CI or dev environment. But I always ignore execution times unless I'm trying to improve them, and I'm sure many users do too. Because I don't want to show them always. If you are serious about making some improvements, you can use |
|
@hsbt -
I'd really like something I can leave on by default in CI/CD, at least. Looking at the high-level: Personally I typically want either:
I think showing the start and the finish (with timing) of installation would be a great default for non- i.e. what if this were the default: And if I'd like to have more timing information I would appreciate having this: When something is slow and I didn't expect it, it's painful to have to redo things with DEBUG because:
What do you think? |
|
Here's a real example: Current default output☝️ Impossible to tell why it took 3 minutes. Especially with higher Suggested default output☝️ Very easy to find out that sqlite3 and grpc were the culprits. And it's no more verbose than the current bundler output. |
|
Another idea, if we want to reduce output even more than we currently are: Limit the default output to just The Just a thought. |
|
👋 The reason I added the timing information during debugging was because I felt that printing it by default wouldn't provide any value to regular users.
I guess the question that remains is: if you were to know that this is slow, do you think this would incline users to investigate the problem and fix it, or would it just be "oh it's slow because of that" ? I see this timing information similar ish to the browser console. On a day to day basis I don't really care to know how long a web page takes to load. But if it annoys me I can rely on the console tools and investigate the issue, but I wouldn't want that console to be turned on all the time. I hope my rationale make sense 😅 |
I think it would definitely encourage them to fix it! Having the data possible via |
|
We don't need to make it much more verbose for the user btw. E.g. change the default from this: To this: Doesn't feel significantly more verbose? But even if we don't change the default, having something reasonable (i.e. not all of DEBUG) that I can leave turned on (e.g. |
4 participants
The recently-added "Installed in" and "Downloaded in" timing outputs are much appreciated 🙏
I'd like to suggest we enable them by default, rather than only when DEBUG=true.
It's very common to:
bundle installduring deploys or CI--jobs> 1When
--jobs> 1, it's impossible to tell which gems are slow, unless "Installed In" is displayed.DEBUG=trueis very verbose, and seems like too much for this common need. This feels like a common enough case to output the new timings by default.We had some discussion of this previously in #7622 and had decided on always displaying the timings.
Or, if we don't want to enable the output by default, would we be ok with adding an
--timingoption, to allow outputing even whenDEBUG=trueis not set?i.e. like:
?
Make sure the following tasks are checked