Emit measurement results immediately #203
Comments
|
Another thing we could do, just to provide feedback that something is happening and the process isn't just hanging, is to print a dot to |
|
To take this one step further, I've been going back and forth about whether we should bring in a progress meter here. We know how many iterations need to be run so it's not hard to keep track of the percentage complete. I even took a look at crates.io at some options but they all seem snazzier (and bigger) than what is needed here. |
|
As someone who's spent a good amount of time staring at a sightglass invocation waiting for it to finish... some indication, even just "1% ... 2% ... 3% ... " textual output (adjust step size as desired), of how long I might be waiting would be very welcome! I've resorted to turning up |
|
I would personally want to avoid any fancy progress bar, since it seems like it might introduce unnecessary noise into the system and seems a bit overkill. |
|
Ok, no progress bars. One thing I just looked up is whether we could detect an ANSI terminal and just rewrite the same line; seems like it might work with |
|
Even simpler, just newlines? Perhaps with a |
This change emits a string to `stderr` that indicates how far Sightglass has come in running its benchmarks: ``` Iterations completed: 42/100 ``` The idea is to provide more immediate and clear feedback than `RUST_LOG` that Sightglass is doing work and the user can wait for it to finish. This turns out to be rather tricky to do due to the single-process and multi-process paradigms for running benchmarks; the solution is to communicate here with an internal environment variable "protocol." The other tricky bit is the addition of ANSI terminal escape codes. This allows Sightglass to overwrite the same line and avoid filling up a screen with repeated `Iterations completed: ...` messages. This part of the PR could be safely removed without change to the counting functionality but I hope that the implementation is simple enough--and pessimistic enough--that it should not cause trouble down the road. I say "pessimistic" because the heuristic for determining if a terminal can support these "overwriting" terminal codes should just default to printing extra lines if anything looks amiss. This PR is related to bytecodealliance#203 and may close that issue.
@jameysharp mentioned in #202 (comment) that it would be nice if measurement results were emitted as soon as they were collected. Currently this is not the case: all the measurements for all of the benchmark runs are collected and emitted at the end. This issue could be fixable by refactoring how the measurements are serialized by
serde.The text was updated successfully, but these errors were encountered: