Sub-second precision for `elapsed`.

[lgarron]

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.

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]

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]

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 

[djc]

• 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?

[tropicaaal]

• 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]

It's already possible to make a custom ProgressTracker.

[powerpellet1077]

Is this still in the works? I would love to see this get finalized.

[lgarron]

Is this still in the works? I would love to see this get finalized.

Unfortunately I've had too many other priorities to neaten up the PR and have been using a vendored fork. I'd be glad for someone else to pick it up.

[djc]

I've submitted a PR:

• Allow HumanDuration to be more precise for sub-second durations #783