-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
feat(bench): Add JSON reporter for "deno bench" subcommand #17595
Conversation
output format: ``` [ { "runtime": "Deno/1.28.3 x86_64-apple-darwin", "cpu": "Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz", "origin": "file:///Users/serhiy.barhamon/tmp/deno/test_ffi/tests/bench.js", "group": null, "name": "Deno.UnsafePointerView#getUint32", "baseline": false, "result": { "ok": { "n": 49, "min": 1251.9348, "max": 1441.2696, "avg": 1308.7523755102038, "p75": 1324.1055, "p99": 1441.2696, "p995": 1441.2696, "p999": 1441.2696 } } } ] ``` time unit: nanoseconds
I think I am done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from the output format, LGTM. Core team should probably chime in on if the output format should be a flat list like it is now, or a structured object that aligns a bit more with the semantics of the bench command.
@@ -123,6 +132,74 @@ pub trait BenchReporter { | |||
fn report_result(&mut self, desc: &BenchDescription, result: &BenchResult); | |||
} | |||
|
|||
#[derive(Debug, Serialize)] | |||
struct JsonReporterResult { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bikeshedding: I would perhaps split up the formatting a bit; now each result field includes the runtime and CPU information, and groups are only an entry in the result data and not actually groups as the name might suggest.
I might rather go with something like:
{
"runtime": "...",
"cpu": "...",
"groups": [
{
"name": null,
"results": [
{
"name": "nop()",
"origin": "file.js",
"baseline": false,
"result": { "ok": { } }
}
]
}
]
}
|
||
fn report_result(&mut self, desc: &BenchDescription, result: &BenchResult) { | ||
self.0.push(JsonReporterResult::new( | ||
desc.origin.clone(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doc JSON output uses location.filename
(together with location.line
and location.col
, and the error stack uses fileName
. Maybe align with either or?
@aapoalas On the output format.
A flat structure is much better in use cases like that. But I am ready to change it if my assumptions are wrong. |
cli/args/flags.rs
Outdated
.arg( | ||
Arg::new("json") | ||
.long("json") | ||
.help("Output benchmark result in JSON format") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add UNSTABLE:
to the help string for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
cli/args/flags.rs
Outdated
@@ -751,6 +758,10 @@ and report results to standard output: | |||
|
|||
deno bench src/fetch_bench.ts src/signal_bench.ts | |||
|
|||
Output benchmark result in JSON format: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't really needed I think, the --help
will print out the individual args either way so this will just be redundant information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed
Sounds like a good enough reason to go with your choice format. I kind of would expect the workflow to go otherwise the same but with some processing step between running and saving to a database, where massaging would be done and at that point it might be useful to have the data already eg. grouped up so the massaging wouldn't need to start with a "divide into groups" step. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. We can iterate on the exact format down the line.
Initial discussion in #14385
In this pull request:
New
--json
flag to bench subcommand.time unit: nanoseconds.
Output format example: