2024-03-09 17:59:55 +01:00
|
|
|
use nu_cli::{eval_source, evaluate_commands};
|
2024-04-27 19:08:12 +02:00
|
|
|
use nu_plugin_core::{Encoder, EncodingType};
|
|
|
|
use nu_plugin_protocol::{PluginCallResponse, PluginOutput};
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
|
2024-02-27 18:55:26 +01:00
|
|
|
use nu_protocol::{
|
2024-03-26 16:17:44 +01:00
|
|
|
engine::{EngineState, Stack},
|
|
|
|
eval_const::create_nu_constant,
|
|
|
|
PipelineData, Span, Spanned, Value, NU_VARIABLE_ID,
|
2024-02-27 18:55:26 +01:00
|
|
|
};
|
2024-03-09 17:59:55 +01:00
|
|
|
use nu_std::load_standard_library;
|
2023-01-11 02:51:25 +01:00
|
|
|
use nu_utils::{get_default_config, get_default_env};
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
use std::{
|
|
|
|
path::{Path, PathBuf},
|
|
|
|
rc::Rc,
|
|
|
|
};
|
2023-01-11 02:51:25 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
use std::hint::black_box;
|
|
|
|
|
|
|
|
use tango_bench::{benchmark_fn, tango_benchmarks, tango_main, IntoBenchmarks};
|
2024-03-01 19:09:21 +01:00
|
|
|
|
2023-06-17 14:41:29 +02:00
|
|
|
fn load_bench_commands() -> EngineState {
|
|
|
|
nu_command::add_shell_command_context(nu_cmd_lang::create_default_context())
|
|
|
|
}
|
2023-12-07 15:13:50 +01:00
|
|
|
|
|
|
|
fn canonicalize_path(engine_state: &EngineState, path: &Path) -> PathBuf {
|
Migrate to a new PWD API (#12603)
This is the first PR towards migrating to a new `$env.PWD` API that
returns potentially un-canonicalized paths. Refer to PR #12515 for
motivations.
## New API: `EngineState::cwd()`
The goal of the new API is to cover both parse-time and runtime use
case, and avoid unintentional misuse. It takes an `Option<Stack>` as
argument, which if supplied, will search for `$env.PWD` on the stack in
additional to the engine state. I think with this design, there's less
confusion over parse-time and runtime environments. If you have access
to a stack, just supply it; otherwise supply `None`.
## Deprecation of other PWD-related APIs
Other APIs are re-implemented using `EngineState::cwd()` and properly
documented. They're marked deprecated, but their behavior is unchanged.
Unused APIs are deleted, and code that accesses `$env.PWD` directly
without using an API is rewritten.
Deprecated APIs:
* `EngineState::current_work_dir()`
* `StateWorkingSet::get_cwd()`
* `env::current_dir()`
* `env::current_dir_str()`
* `env::current_dir_const()`
* `env::current_dir_str_const()`
Other changes:
* `EngineState::get_cwd()` (deleted)
* `StateWorkingSet::list_env()` (deleted)
* `repl::do_run_cmd()` (rewritten with `env::current_dir_str()`)
## `cd` and `pwd` now use logical paths by default
This pulls the changes from PR #12515. It's currently somewhat broken
because using non-canonicalized paths exposed a bug in our path
normalization logic (Issue #12602). Once that is fixed, this should
work.
## Future plans
This PR needs some tests. Which test helpers should I use, and where
should I put those tests?
I noticed that unquoted paths are expanded within `eval_filepath()` and
`eval_directory()` before they even reach the `cd` command. This means
every paths is expanded twice. Is this intended?
Once this PR lands, the plan is to review all usages of the deprecated
APIs and migrate them to `EngineState::cwd()`. In the meantime, these
usages are annotated with `#[allow(deprecated)]` to avoid breaking CI.
---------
Co-authored-by: Jakub Žádník <kubouch@gmail.com>
2024-05-03 13:33:09 +02:00
|
|
|
#[allow(deprecated)]
|
2023-12-07 15:13:50 +01:00
|
|
|
let cwd = engine_state.current_work_dir();
|
|
|
|
|
|
|
|
if path.exists() {
|
|
|
|
match nu_path::canonicalize_with(path, cwd) {
|
|
|
|
Ok(canon_path) => canon_path,
|
|
|
|
Err(_) => path.to_owned(),
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
path.to_owned()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn get_home_path(engine_state: &EngineState) -> PathBuf {
|
2023-12-16 21:06:42 +01:00
|
|
|
nu_path::home_dir()
|
|
|
|
.map(|path| canonicalize_path(engine_state, &path))
|
|
|
|
.unwrap_or_default()
|
2023-12-07 15:13:50 +01:00
|
|
|
}
|
|
|
|
|
2024-03-01 19:09:21 +01:00
|
|
|
fn setup_engine() -> EngineState {
|
2023-06-17 14:41:29 +02:00
|
|
|
let mut engine_state = load_bench_commands();
|
2023-12-07 15:13:50 +01:00
|
|
|
let home_path = get_home_path(&engine_state);
|
|
|
|
|
|
|
|
// parsing config.nu breaks without PWD set, so set a valid path
|
2023-01-11 02:51:25 +01:00
|
|
|
engine_state.add_env_var(
|
|
|
|
"PWD".into(),
|
2023-12-07 15:13:50 +01:00
|
|
|
Value::string(home_path.to_string_lossy(), Span::test_data()),
|
2023-01-11 02:51:25 +01:00
|
|
|
);
|
|
|
|
|
2024-03-01 19:09:21 +01:00
|
|
|
let nu_const = create_nu_constant(&engine_state, Span::unknown())
|
|
|
|
.expect("Failed to create nushell constant.");
|
|
|
|
engine_state.set_variable_const_val(NU_VARIABLE_ID, nu_const);
|
|
|
|
|
|
|
|
engine_state
|
2023-01-11 02:51:25 +01:00
|
|
|
}
|
|
|
|
|
2024-03-26 16:17:44 +01:00
|
|
|
fn setup_stack_and_engine_from_command(command: &str) -> (Stack, EngineState) {
|
|
|
|
let mut engine = setup_engine();
|
|
|
|
let commands = Spanned {
|
|
|
|
span: Span::unknown(),
|
|
|
|
item: command.to_string(),
|
|
|
|
};
|
|
|
|
|
|
|
|
let mut stack = Stack::new();
|
|
|
|
evaluate_commands(
|
|
|
|
&commands,
|
|
|
|
&mut engine,
|
|
|
|
&mut stack,
|
|
|
|
PipelineData::empty(),
|
|
|
|
None,
|
2024-04-09 16:04:00 +02:00
|
|
|
false,
|
2024-03-26 16:17:44 +01:00
|
|
|
)
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
(stack, engine)
|
|
|
|
}
|
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
// generate a new table data with `row_cnt` rows, `col_cnt` columns.
|
|
|
|
fn encoding_test_data(row_cnt: usize, col_cnt: usize) -> Value {
|
|
|
|
let record = Value::test_record(
|
|
|
|
(0..col_cnt)
|
|
|
|
.map(|x| (format!("col_{x}"), Value::test_int(x as i64)))
|
|
|
|
.collect(),
|
|
|
|
);
|
2023-12-07 15:13:50 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
Value::list(vec![record; row_cnt], Span::test_data())
|
2024-03-09 17:59:55 +01:00
|
|
|
}
|
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_command(
|
|
|
|
name: &str,
|
|
|
|
command: &str,
|
|
|
|
stack: Stack,
|
|
|
|
engine: EngineState,
|
|
|
|
) -> impl IntoBenchmarks {
|
|
|
|
let commands = Spanned {
|
|
|
|
span: Span::unknown(),
|
|
|
|
item: command.to_string(),
|
|
|
|
};
|
|
|
|
[benchmark_fn(name, move |b| {
|
|
|
|
let commands = commands.clone();
|
|
|
|
let stack = stack.clone();
|
|
|
|
let engine = engine.clone();
|
|
|
|
b.iter(move || {
|
|
|
|
let mut stack = stack.clone();
|
|
|
|
let mut engine = engine.clone();
|
|
|
|
black_box(
|
|
|
|
evaluate_commands(
|
|
|
|
&commands,
|
|
|
|
&mut engine,
|
|
|
|
&mut stack,
|
|
|
|
PipelineData::empty(),
|
|
|
|
None,
|
|
|
|
false,
|
|
|
|
)
|
|
|
|
.unwrap(),
|
|
|
|
);
|
|
|
|
})
|
|
|
|
})]
|
|
|
|
}
|
2024-03-26 16:17:44 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_eval_source(
|
|
|
|
name: &str,
|
|
|
|
fname: String,
|
|
|
|
source: Vec<u8>,
|
|
|
|
stack: Stack,
|
|
|
|
engine: EngineState,
|
|
|
|
) -> impl IntoBenchmarks {
|
|
|
|
[benchmark_fn(name, move |b| {
|
|
|
|
let stack = stack.clone();
|
|
|
|
let engine = engine.clone();
|
|
|
|
let fname = fname.clone();
|
|
|
|
let source = source.clone();
|
|
|
|
b.iter(move || {
|
|
|
|
let mut stack = stack.clone();
|
|
|
|
let mut engine = engine.clone();
|
|
|
|
let fname: &str = &fname.clone();
|
|
|
|
let source: &[u8] = &source.clone();
|
|
|
|
black_box(eval_source(
|
|
|
|
&mut engine,
|
|
|
|
&mut stack,
|
|
|
|
source,
|
|
|
|
fname,
|
|
|
|
PipelineData::empty(),
|
|
|
|
false,
|
|
|
|
));
|
|
|
|
})
|
|
|
|
})]
|
|
|
|
}
|
2024-03-09 17:59:55 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
/// Load the standard library into the engine.
|
|
|
|
fn bench_load_standard_lib() -> impl IntoBenchmarks {
|
|
|
|
[benchmark_fn("load_standard_lib", move |b| {
|
|
|
|
let engine = setup_engine();
|
|
|
|
b.iter(move || {
|
|
|
|
let mut engine = engine.clone();
|
|
|
|
load_standard_library(&mut engine)
|
|
|
|
})
|
|
|
|
})]
|
|
|
|
}
|
2024-03-09 17:59:55 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn create_flat_record_string(n: i32) -> String {
|
|
|
|
let mut s = String::from("let record = {");
|
|
|
|
for i in 0..n {
|
|
|
|
s.push_str(&format!("col_{}: {}", i, i));
|
|
|
|
if i < n - 1 {
|
|
|
|
s.push_str(", ");
|
2024-03-26 16:17:44 +01:00
|
|
|
}
|
|
|
|
}
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
s.push('}');
|
|
|
|
s
|
|
|
|
}
|
2024-03-26 16:17:44 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn create_nested_record_string(depth: i32) -> String {
|
|
|
|
let mut s = String::from("let record = {");
|
|
|
|
for _ in 0..depth {
|
|
|
|
s.push_str("col: {");
|
2024-03-26 16:17:44 +01:00
|
|
|
}
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
s.push_str("col_final: 0");
|
|
|
|
for _ in 0..depth {
|
|
|
|
s.push('}');
|
2024-03-26 16:17:44 +01:00
|
|
|
}
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
s.push('}');
|
|
|
|
s
|
2024-03-26 16:17:44 +01:00
|
|
|
}
|
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn create_example_table_nrows(n: i32) -> String {
|
|
|
|
let mut s = String::from("let table = [[foo bar baz]; ");
|
|
|
|
for i in 0..n {
|
|
|
|
s.push_str(&format!("[0, 1, {i}]"));
|
|
|
|
if i < n - 1 {
|
|
|
|
s.push_str(", ");
|
2024-03-26 18:59:52 +01:00
|
|
|
}
|
|
|
|
}
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
s.push(']');
|
|
|
|
s
|
|
|
|
}
|
2024-03-26 18:59:52 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_record_create(n: i32) -> impl IntoBenchmarks {
|
|
|
|
bench_command(
|
|
|
|
&format!("record_create_{n}"),
|
|
|
|
&create_flat_record_string(n),
|
|
|
|
Stack::new(),
|
|
|
|
setup_engine(),
|
|
|
|
)
|
2024-03-26 18:59:52 +01:00
|
|
|
}
|
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_record_flat_access(n: i32) -> impl IntoBenchmarks {
|
|
|
|
let setup_command = create_flat_record_string(n);
|
|
|
|
let (stack, engine) = setup_stack_and_engine_from_command(&setup_command);
|
|
|
|
bench_command(
|
|
|
|
&format!("record_flat_access_{n}"),
|
|
|
|
"$record.col_0 | ignore",
|
|
|
|
stack,
|
|
|
|
engine,
|
|
|
|
)
|
|
|
|
}
|
2024-03-26 16:17:44 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_record_nested_access(n: i32) -> impl IntoBenchmarks {
|
|
|
|
let setup_command = create_nested_record_string(n);
|
|
|
|
let (stack, engine) = setup_stack_and_engine_from_command(&setup_command);
|
|
|
|
let nested_access = ".col".repeat(n as usize);
|
|
|
|
bench_command(
|
|
|
|
&format!("record_nested_access_{n}"),
|
|
|
|
&format!("$record{} | ignore", nested_access),
|
|
|
|
stack,
|
|
|
|
engine,
|
|
|
|
)
|
|
|
|
}
|
2024-03-12 13:10:37 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_table_create(n: i32) -> impl IntoBenchmarks {
|
|
|
|
bench_command(
|
|
|
|
&format!("table_create_{n}"),
|
|
|
|
&create_example_table_nrows(n),
|
|
|
|
Stack::new(),
|
|
|
|
setup_engine(),
|
|
|
|
)
|
|
|
|
}
|
2024-03-09 17:59:55 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_table_get(n: i32) -> impl IntoBenchmarks {
|
|
|
|
let setup_command = create_example_table_nrows(n);
|
|
|
|
let (stack, engine) = setup_stack_and_engine_from_command(&setup_command);
|
|
|
|
bench_command(
|
|
|
|
&format!("table_get_{n}"),
|
|
|
|
"$table | get bar | math sum | ignore",
|
|
|
|
stack,
|
|
|
|
engine,
|
|
|
|
)
|
|
|
|
}
|
2024-03-09 17:59:55 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_table_select(n: i32) -> impl IntoBenchmarks {
|
|
|
|
let setup_command = create_example_table_nrows(n);
|
|
|
|
let (stack, engine) = setup_stack_and_engine_from_command(&setup_command);
|
|
|
|
bench_command(
|
|
|
|
&format!("table_select_{n}"),
|
|
|
|
"$table | select foo baz | ignore",
|
|
|
|
stack,
|
|
|
|
engine,
|
|
|
|
)
|
|
|
|
}
|
2024-03-09 17:59:55 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_eval_interleave(n: i32) -> impl IntoBenchmarks {
|
|
|
|
let engine = setup_engine();
|
|
|
|
let stack = Stack::new();
|
|
|
|
bench_command(
|
|
|
|
&format!("eval_interleave_{n}"),
|
|
|
|
&format!("seq 1 {n} | wrap a | interleave {{ seq 1 {n} | wrap b }} | ignore"),
|
|
|
|
stack,
|
|
|
|
engine,
|
|
|
|
)
|
|
|
|
}
|
2024-03-12 13:10:37 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_eval_interleave_with_ctrlc(n: i32) -> impl IntoBenchmarks {
|
|
|
|
let mut engine = setup_engine();
|
|
|
|
engine.ctrlc = Some(std::sync::Arc::new(std::sync::atomic::AtomicBool::new(
|
|
|
|
false,
|
|
|
|
)));
|
|
|
|
let stack = Stack::new();
|
|
|
|
bench_command(
|
|
|
|
&format!("eval_interleave_with_ctrlc_{n}"),
|
|
|
|
&format!("seq 1 {n} | wrap a | interleave {{ seq 1 {n} | wrap b }} | ignore"),
|
|
|
|
stack,
|
|
|
|
engine,
|
|
|
|
)
|
2024-03-09 17:59:55 +01:00
|
|
|
}
|
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_eval_for(n: i32) -> impl IntoBenchmarks {
|
|
|
|
let engine = setup_engine();
|
|
|
|
let stack = Stack::new();
|
|
|
|
bench_command(
|
|
|
|
&format!("eval_for_{n}"),
|
|
|
|
&format!("(for $x in (1..{n}) {{ 1 }}) | ignore"),
|
|
|
|
stack,
|
|
|
|
engine,
|
|
|
|
)
|
|
|
|
}
|
2023-12-07 15:13:50 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_eval_each(n: i32) -> impl IntoBenchmarks {
|
|
|
|
let engine = setup_engine();
|
|
|
|
let stack = Stack::new();
|
|
|
|
bench_command(
|
|
|
|
&format!("eval_each_{n}"),
|
|
|
|
&format!("(1..{n}) | each {{|_| 1 }} | ignore"),
|
|
|
|
stack,
|
|
|
|
engine,
|
|
|
|
)
|
|
|
|
}
|
2024-03-01 19:09:21 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_eval_par_each(n: i32) -> impl IntoBenchmarks {
|
|
|
|
let engine = setup_engine();
|
|
|
|
let stack = Stack::new();
|
|
|
|
bench_command(
|
|
|
|
&format!("eval_par_each_{n}"),
|
|
|
|
&format!("(1..{}) | par-each -t 2 {{|_| 1 }} | ignore", n),
|
|
|
|
stack,
|
|
|
|
engine,
|
|
|
|
)
|
|
|
|
}
|
2024-03-01 19:09:21 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_eval_default_config() -> impl IntoBenchmarks {
|
|
|
|
let default_env = get_default_config().as_bytes().to_vec();
|
|
|
|
let fname = "default_config.nu".to_string();
|
|
|
|
bench_eval_source(
|
|
|
|
"eval_default_config",
|
|
|
|
fname,
|
|
|
|
default_env,
|
|
|
|
Stack::new(),
|
|
|
|
setup_engine(),
|
|
|
|
)
|
|
|
|
}
|
2024-03-01 19:09:21 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn bench_eval_default_env() -> impl IntoBenchmarks {
|
|
|
|
let default_env = get_default_env().as_bytes().to_vec();
|
|
|
|
let fname = "default_env.nu".to_string();
|
|
|
|
bench_eval_source(
|
|
|
|
"eval_default_env",
|
|
|
|
fname,
|
|
|
|
default_env,
|
|
|
|
Stack::new(),
|
|
|
|
setup_engine(),
|
|
|
|
)
|
2024-03-01 19:09:21 +01:00
|
|
|
}
|
2024-02-27 18:55:26 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn encode_json(row_cnt: usize, col_cnt: usize) -> impl IntoBenchmarks {
|
|
|
|
let test_data = Rc::new(PluginOutput::CallResponse(
|
|
|
|
0,
|
|
|
|
PluginCallResponse::value(encoding_test_data(row_cnt, col_cnt)),
|
|
|
|
));
|
|
|
|
let encoder = Rc::new(EncodingType::try_from_bytes(b"json").unwrap());
|
|
|
|
|
|
|
|
[benchmark_fn(
|
|
|
|
format!("encode_json_{}_{}", row_cnt, col_cnt),
|
|
|
|
move |b| {
|
|
|
|
let encoder = encoder.clone();
|
|
|
|
let test_data = test_data.clone();
|
|
|
|
b.iter(move || {
|
|
|
|
let mut res = Vec::new();
|
|
|
|
encoder.encode(&*test_data, &mut res).unwrap();
|
2024-03-01 19:09:21 +01:00
|
|
|
})
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
},
|
|
|
|
)]
|
|
|
|
}
|
2024-03-01 19:09:21 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn encode_msgpack(row_cnt: usize, col_cnt: usize) -> impl IntoBenchmarks {
|
|
|
|
let test_data = Rc::new(PluginOutput::CallResponse(
|
|
|
|
0,
|
|
|
|
PluginCallResponse::value(encoding_test_data(row_cnt, col_cnt)),
|
|
|
|
));
|
|
|
|
let encoder = Rc::new(EncodingType::try_from_bytes(b"msgpack").unwrap());
|
|
|
|
|
|
|
|
[benchmark_fn(
|
|
|
|
format!("encode_msgpack_{}_{}", row_cnt, col_cnt),
|
|
|
|
move |b| {
|
|
|
|
let encoder = encoder.clone();
|
|
|
|
let test_data = test_data.clone();
|
|
|
|
b.iter(move || {
|
|
|
|
let mut res = Vec::new();
|
|
|
|
encoder.encode(&*test_data, &mut res).unwrap();
|
2024-03-01 19:09:21 +01:00
|
|
|
})
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
},
|
|
|
|
)]
|
2023-01-11 02:51:25 +01:00
|
|
|
}
|
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn decode_json(row_cnt: usize, col_cnt: usize) -> impl IntoBenchmarks {
|
|
|
|
let test_data = PluginOutput::CallResponse(
|
|
|
|
0,
|
|
|
|
PluginCallResponse::value(encoding_test_data(row_cnt, col_cnt)),
|
Create `Record` type (#10103)
# Description
This PR creates a new `Record` type to reduce duplicate code and
possibly bugs as well. (This is an edited version of #9648.)
- `Record` implements `FromIterator` and `IntoIterator` and so can be
iterated over or collected into. For example, this helps with
conversions to and from (hash)maps. (Also, no more
`cols.iter().zip(vals)`!)
- `Record` has a `push(col, val)` function to help insure that the
number of columns is equal to the number of values. I caught a few
potential bugs thanks to this (e.g. in the `ls` command).
- Finally, this PR also adds a `record!` macro that helps simplify
record creation. It is used like so:
```rust
record! {
"key1" => some_value,
"key2" => Value::string("text", span),
"key3" => Value::int(optional_int.unwrap_or(0), span),
"key4" => Value::bool(config.setting, span),
}
```
Since macros hinder formatting, etc., the right hand side values should
be relatively short and sweet like the examples above.
Where possible, prefer `record!` or `.collect()` on an iterator instead
of multiple `Record::push`s, since the first two automatically set the
record capacity and do less work overall.
# User-Facing Changes
Besides the changes in `nu-protocol` the only other breaking changes are
to `nu-table::{ExpandedTable::build_map, JustTable::kv_table}`.
2023-08-24 21:50:29 +02:00
|
|
|
);
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
let encoder = EncodingType::try_from_bytes(b"json").unwrap();
|
|
|
|
let mut res = vec![];
|
|
|
|
encoder.encode(&test_data, &mut res).unwrap();
|
|
|
|
|
|
|
|
[benchmark_fn(
|
|
|
|
format!("decode_json_{}_{}", row_cnt, col_cnt),
|
|
|
|
move |b| {
|
|
|
|
let res = res.clone();
|
|
|
|
b.iter(move || {
|
2024-03-01 19:09:21 +01:00
|
|
|
let mut binary_data = std::io::Cursor::new(res.clone());
|
|
|
|
binary_data.set_position(0);
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
let _: Result<Option<PluginOutput>, _> =
|
|
|
|
black_box(encoder.decode(&mut binary_data));
|
2024-03-01 19:09:21 +01:00
|
|
|
})
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
},
|
|
|
|
)]
|
|
|
|
}
|
2024-03-01 19:09:21 +01:00
|
|
|
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
fn decode_msgpack(row_cnt: usize, col_cnt: usize) -> impl IntoBenchmarks {
|
|
|
|
let test_data = PluginOutput::CallResponse(
|
|
|
|
0,
|
|
|
|
PluginCallResponse::value(encoding_test_data(row_cnt, col_cnt)),
|
|
|
|
);
|
|
|
|
let encoder = EncodingType::try_from_bytes(b"msgpack").unwrap();
|
|
|
|
let mut res = vec![];
|
|
|
|
encoder.encode(&test_data, &mut res).unwrap();
|
|
|
|
|
|
|
|
[benchmark_fn(
|
|
|
|
format!("decode_msgpack_{}_{}", row_cnt, col_cnt),
|
|
|
|
move |b| {
|
|
|
|
let res = res.clone();
|
|
|
|
b.iter(move || {
|
2024-03-01 19:09:21 +01:00
|
|
|
let mut binary_data = std::io::Cursor::new(res.clone());
|
|
|
|
binary_data.set_position(0);
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
let _: Result<Option<PluginOutput>, _> =
|
|
|
|
black_box(encoder.decode(&mut binary_data));
|
2024-03-01 19:09:21 +01:00
|
|
|
})
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
},
|
|
|
|
)]
|
2024-03-01 19:09:21 +01:00
|
|
|
}
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
|
|
|
|
tango_benchmarks!(
|
|
|
|
bench_load_standard_lib(),
|
|
|
|
// Data types
|
|
|
|
// Record
|
|
|
|
bench_record_create(1),
|
|
|
|
bench_record_create(10),
|
|
|
|
bench_record_create(100),
|
|
|
|
bench_record_create(1_000),
|
|
|
|
bench_record_flat_access(1),
|
|
|
|
bench_record_flat_access(10),
|
|
|
|
bench_record_flat_access(100),
|
|
|
|
bench_record_flat_access(1_000),
|
|
|
|
bench_record_nested_access(1),
|
|
|
|
bench_record_nested_access(2),
|
|
|
|
bench_record_nested_access(4),
|
|
|
|
bench_record_nested_access(8),
|
|
|
|
bench_record_nested_access(16),
|
|
|
|
bench_record_nested_access(32),
|
|
|
|
bench_record_nested_access(64),
|
|
|
|
bench_record_nested_access(128),
|
|
|
|
// Table
|
|
|
|
bench_table_create(1),
|
|
|
|
bench_table_create(10),
|
|
|
|
bench_table_create(100),
|
|
|
|
bench_table_create(1_000),
|
|
|
|
bench_table_get(1),
|
|
|
|
bench_table_get(10),
|
|
|
|
bench_table_get(100),
|
|
|
|
bench_table_get(1_000),
|
|
|
|
bench_table_select(1),
|
|
|
|
bench_table_select(10),
|
|
|
|
bench_table_select(100),
|
|
|
|
bench_table_select(1_000),
|
|
|
|
// Eval
|
|
|
|
// Interleave
|
|
|
|
bench_eval_interleave(100),
|
|
|
|
bench_eval_interleave(1_000),
|
|
|
|
bench_eval_interleave(10_000),
|
|
|
|
bench_eval_interleave_with_ctrlc(100),
|
|
|
|
bench_eval_interleave_with_ctrlc(1_000),
|
|
|
|
bench_eval_interleave_with_ctrlc(10_000),
|
|
|
|
// For
|
|
|
|
bench_eval_for(1),
|
|
|
|
bench_eval_for(10),
|
|
|
|
bench_eval_for(100),
|
|
|
|
bench_eval_for(1_000),
|
|
|
|
bench_eval_for(10_000),
|
|
|
|
// Each
|
|
|
|
bench_eval_each(1),
|
|
|
|
bench_eval_each(10),
|
|
|
|
bench_eval_each(100),
|
|
|
|
bench_eval_each(1_000),
|
|
|
|
bench_eval_each(10_000),
|
|
|
|
// Par-Each
|
|
|
|
bench_eval_par_each(1),
|
|
|
|
bench_eval_par_each(10),
|
|
|
|
bench_eval_par_each(100),
|
|
|
|
bench_eval_par_each(1_000),
|
|
|
|
bench_eval_par_each(10_000),
|
|
|
|
// Config
|
|
|
|
bench_eval_default_config(),
|
|
|
|
// Env
|
|
|
|
bench_eval_default_env(),
|
|
|
|
// Encode
|
|
|
|
// Json
|
|
|
|
encode_json(100, 5),
|
|
|
|
encode_json(10000, 15),
|
|
|
|
// MsgPack
|
|
|
|
encode_msgpack(100, 5),
|
|
|
|
encode_msgpack(10000, 15),
|
|
|
|
// Decode
|
|
|
|
// Json
|
|
|
|
decode_json(100, 5),
|
|
|
|
decode_json(10000, 15),
|
|
|
|
// MsgPack
|
|
|
|
decode_msgpack(100, 5),
|
|
|
|
decode_msgpack(10000, 15)
|
|
|
|
);
|
|
|
|
|
|
|
|
tango_main!();
|