Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sub-second precision for elapsed. #597

Open
lgarron opened this issue Oct 6, 2023 · 5 comments
Open

Sub-second precision for elapsed. #597

lgarron opened this issue Oct 6, 2023 · 5 comments

Comments

@lgarron
Copy link

lgarron commented Oct 6, 2023

I've been happily using indicatif for a few use cases, and just applied it to tracking how long certain dependencies take to build: https://github.com/lgarron/mak

"Unfortunately", I've optimized the builds and tests for one of my projects so well that many of the steps take less than a second.

demo

Would it be possible to enable sub-second precision for elapsed so I can see how long the steps took to run?

I'd be glad for a way to specify 3 decimal digits of precision, since some commands can be in the range of 10ms.

@djc
Copy link
Member

djc commented Oct 6, 2023

I'm open to having the logic changed so that it shows milliseconds instead of seconds past some threshold. Are you able to submit a PR for this? I think it might be enough to add millisecond value to UNITS here: https://github.com/console-rs/indicatif/blob/main/src/format.rs#L106.

@lgarron
Copy link
Author

lgarron commented Oct 6, 2023

ooh, that definitely was easy!

🎯|    3s |   ↙ test-spec-bun
🎯|    5s |   ↙ test-spec-dom
🎯|  17ms |  ↙ test-spec
🎯| 854ms |  ↙ lint-ci
🎯|    7s |  ↙ test-src-tsc
🎯| 353ms |   ↙ build-lib-js
🎯| 953ms |  ↙ test-src-import-restrictions
🎯|  42ms |  ↙ test-src-scripts-consistency
🎯|   9ms | ↙ test-src
🎯| 121ms |  ↙ build-bin
🎯|   14s |  ↙ build-lib-types
🎯| 726ms |   ↙ build-site-twizzle
🎯| 569ms |   ↙ build-site-experiments
🎯|  14ms |  ↙ build-sites
🎯|    8s |  ↙ build-site-docs
🎯|   7ms | ↙ test-build
🎯|    4s |   ↙ test-dist-lib-node-import
🎯|   10s |   ↙ test-dist-lib-node-scramble-all-events
🎯|    4s |   ↙ test-dist-lib-perf
🎯|    4s |   ↙ test-dist-lib-plain-esbuild-compat
🎯|    4s |   ↙ test-dist-lib-build-size
🎯|    2s |   ↙ test-dist-sites-experiments
🎯|   7ms |  ↙ test-dist-lib
🎯|    3s |   ↙ test-dist-bin-shebang
🎯|    3s |   ↙ test-dist-bin-npm-exec
🎯|  21ms |  ↙ test-dist-bin
🎯|   7ms | ↙ test-dist
🎯|   6ms | test-all                                                     

Some thoughts:

  • I can imagine that could result in undesirable increased visual activity / layout changes for some use cases. Should I try to make it opt-in?
  • Should I leave elapsed_precise alone?
  • Would you be open to seconds with decimal digits? Times under 1000ms are accurate, but the precision drastically drops for times in the low seconds. It could also help with visual scanability, e.g. to avoid making 7ms look "larger" than 8s.

If I could perfectly tune it, I'd probably go for this:

🎯|  2.20s |   ↙ test-spec-bun
🎯|  5.02s |   ↙ test-spec-dom
🎯|  0.01s |  ↙ test-spec
🎯|  0.74s |  ↙ lint-ci
🎯|  8.01s |  ↙ test-src-tsc
🎯|  0.34s |   ↙ build-lib-js
🎯|  0.76s |  ↙ test-src-import-restrictions
🎯|  0.05s |  ↙ test-src-scripts-consistency
🎯|  0.01s | ↙ test-src
🎯|  0.12s |  ↙ build-bin
🎯| 14.81s |  ↙ build-lib-types
🎯|  0.71s |   ↙ build-site-twizzle
🎯|  2.47s |   ↙ build-site-experiments
🎯|  0.11s |  ↙ build-sites
🎯|  8.28s |  ↙ build-site-docs
🎯|  0.00s | ↙ test-build
🎯|  2.20s |   ↙ test-dist-lib-node-import
🎯| 10.90s |   ↙ test-dist-lib-node-scramble-all-events
🎯|  2.19s |   ↙ test-dist-lib-perf
🎯|  2.19s |   ↙ test-dist-lib-plain-esbuild-compat
🎯|  2.19s |   ↙ test-dist-lib-build-size
🎯|  1.00s |   ↙ test-dist-sites-experiments
🎯|  0.00s |  ↙ test-dist-lib
🎯|  2.30s |   ↙ test-dist-bin-shebang
🎯|  2.30s |   ↙ test-dist-bin-npm-exec
🎯|  0.01s |  ↙ test-dist-bin
🎯|  0.00s | ↙ test-dist
🎯|  0.01s | test-all 

lgarron added a commit to lgarron/indicatif that referenced this issue Oct 6, 2023
lgarron added a commit to lgarron/indicatif that referenced this issue Oct 6, 2023
lgarron added a commit to lgarron/indicatif that referenced this issue Oct 6, 2023
@djc
Copy link
Member

djc commented Oct 9, 2023

  • I'd prefer to avoid making it configurable/opt-in, but making it good (enough) for everyone instead.
  • Would probably be nice to add milliseconds to _precise, too.
  • Yes, I agree that might make more sense. Maybe do 0.2f for values less than 2s?

@Tropix126
Copy link

Tropix126 commented Jun 29, 2024

  • I'd prefer to avoid making it configurable/opt-in, but making it good (enough) for everyone instead.

I'm fairly late to this issue, but i dont think this is very realistic, especially for elapsed_precise, where the people will want different things based on how long their specific implementation is expected to take. This also could apply to percent_precise if someone wanted (for example) to have a custom precision amount on the percentage formatting. Would adding some sort of configuration to the style format strings or method for custom formatting be viable here?

@djc
Copy link
Member

djc commented Jun 29, 2024

It's already possible to make a custom ProgressTracker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants