about summary refs log tree commit diff
path: root/tvix/glue/benches
AgeCommit message (Collapse)AuthorFilesLines
2024-07-22 r/8399 refactor(tvix): move service addrs into shared clap structYureka1-2/+5
Change-Id: I7cab29ecfa1823c2103b4c47b7d784bc31459d55 Reviewed-on: https://cl.tvl.fyi/c/depot/+/12008 Tested-by: BuildkiteCI Reviewed-by: flokli <flokli@flokli.de> Autosubmit: yuka <yuka@yuka.dev>
2024-07-20 r/8380 refactor(tvix/store): use composition in tvix_store crateYureka1-1/+1
Change-Id: Ie6290b296baba2b987f1a61c9bb4c78549ac11f1 Reviewed-on: https://cl.tvl.fyi/c/depot/+/11983 Reviewed-by: flokli <flokli@flokli.de> Autosubmit: yuka <yuka@yuka.dev> Tested-by: BuildkiteCI
2024-07-06 r/8351 refactor(tvix/eval): Builderize EvaluationAspen Smith1-10/+11
Make constructing of a new Evaluation use the builder pattern rather than setting public mutable fields. This is currently a pure refactor (no functionality has changed) but has a few advantages: - We've encapsulated the internals of the fields in Evaluation, meaning we can change them without too much breakage of clients - We have type safety that prevents us from ever changing the fields of an Evaluation after it's built (which matters more in a world where we reuse Evaluations). More importantly, this paves the road for doing different things with the construction of an Evaluation - notably, sharing certain things like the GlobalsMap across subsequent evaluations in eg the REPL. Fixes: b/262 Change-Id: I4a27116faac14cdd144fc7c992d14ae095a1aca4 Reviewed-on: https://cl.tvl.fyi/c/depot/+/11956 Tested-by: BuildkiteCI Autosubmit: aspen <root@gws.fyi> Reviewed-by: flokli <flokli@flokli.de>
2024-06-06 r/8222 feat(tvix): Switch to jemallocAspen Smith1-0/+6
Switch tvix to using jemalloc as the default global allocator on supported (eg, non-msvc) platforms. This gives a pretty reasonable performance boost basically for free: int time: [24.361 µs 24.386 µs 24.418 µs] change: [-19.355% -18.859% -18.527%] (p = 0.00 < 0.05) Performance has improved. merge small attrs time: [37.201 µs 37.328 µs 37.442 µs] change: [-24.609% -24.266% -23.982%] (p = 0.00 < 0.05) Performance has improved. merge large attrs with small attrs time: [20.030 ms 20.135 ms 20.251 ms] change: [-4.2811% -3.2549% -2.3807%] (p = 0.00 < 0.05) Performance has improved. hello outpath time: [967.91 ms 974.07 ms 983.33 ms] change: [-5.5008% -4.4552% -3.4099%] (p = 0.00 < 0.05) Performance has improved. Change-Id: I6c6e6e3295ec2fca01ea28dc37bcb201cd811767 Reviewed-on: https://cl.tvl.fyi/c/depot/+/10851 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org> Autosubmit: aspen <root@gws.fyi> Reviewed-by: flokli <flokli@flokli.de>
2024-05-11 r/8103 refactor(tvix/store): drop calculate_nar from PathInfoServiceFlorian Klink1-15/+9
This shouldn't be part of the PathInfoService trait. Pretty much none of the PathInfoServices do implement it, and requiring them to implement it means they also cannot make use of this calculation already being done by other PathInfoServices. Move it out into its own NarCalculationService trait, defined somewhere at tvix_store::nar, and have everyone who wants to trigger nar calculation use nar_calculation_service directly, which now is an additional field in TvixStoreIO for example. It being moved outside the PathInfoService trait doesn't prohibit specific implementations to implement it (like the GRPC client for the `PathInfoService` does. This is currently wired together in a bit of a hacky fashion - as of now, everything uses the naive implementation that traverses blob and directoryservice, rather than composing it properly. I want to leave that up to a later CL, dealing with other parts of store composition too. Change-Id: I18d07ea4301d4a07651b8218bc5fe95e4e307208 Reviewed-on: https://cl.tvl.fyi/c/depot/+/11619 Reviewed-by: Connor Brewster <cbrewster@hey.com> Autosubmit: flokli <flokli@flokli.de> Tested-by: BuildkiteCI
2024-02-21 r/7588 revert(tvix): don't use Rc::clone explicitlyaspen1-2/+2
This reverts commit d9565a4d0af3bffd735a77aa6f1fd0ec0e03b14a. Reason for revert: this was intentional - putting Rc::clone instead of .clone is a common Rust idiom, and makes it explicit that we're cloning a shared reference, not an underlying resource Change-Id: I41a5f323ee35d7025dc7bb02f7d5d05d0051798d Reviewed-on: https://cl.tvl.fyi/c/depot/+/10995 Tested-by: BuildkiteCI Reviewed-by: flokli <flokli@flokli.de>
2024-02-20 r/7578 feat(tvix/eval): implement `builtins.filterSource`Ryan Lahfa1-2/+3
We add a new set of builtins called `import_builtins`, which will contain import-related builtins, such as `builtins.path` and `builtins.filterSource`. Both can import paths into the store, with various knobs to alter the result, e.g. filtering, renaming, expected hashes. We introduce `filtered_ingest` which will drive the filtered ingestion via the Nix function via the generator machinery, and then we register the root node to the path info service inside the store. `builtins.filterSource` is very simple, `builtins.path` is a more complicated model requiring the same logic albeit more sophisticated with name customization, file ingestion method and expected SHA-256. Change-Id: I1083f37808b35f7b37818c8ffb9543d9682b2de2 Reviewed-on: https://cl.tvl.fyi/c/depot/+/10654 Autosubmit: raitobezarius <tvl@lahfa.xyz> Tested-by: BuildkiteCI Reviewed-by: flokli <flokli@flokli.de>
2024-02-20 r/7576 refactor(tvix): don't use Rc::clone explicitlyFlorian Klink1-1/+1
All these functions have an Rc of Rc<TvixStoreIO> or Rc<dyn StoreIO>, so we can call io.clone() directly. Change-Id: I96a5bcb9af4aca93892cb72bcfaf14540da52381 Reviewed-on: https://cl.tvl.fyi/c/depot/+/10989 Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su>
2024-02-19 r/7557 feat(tvix/glue): Init fetcher builtinsAspen Smith1-2/+5
Initialize a new empty builtins module `fetcher_builtins`, which will contain the builtins which fetch URLs from the internet: * fetchurl * fetchGit * fetchTarball * fetchTree (maybe? this is experimental) These builtins are all implemented in CPP nix at: https://github.com/NixOS/nix/blob/2.20.2/src/libexpr/primops/fetchTree.cc These builtins are added to the evaluation context using a similar mechanism to the derivation builtins, and have been added everywhere derivation builtins were previously being added. Change-Id: I133b91cc9560f23028621414537f712e7bd8a825 Reviewed-on: https://cl.tvl.fyi/c/depot/+/10974 Autosubmit: aspen <root@gws.fyi> Reviewed-by: flokli <flokli@flokli.de> Tested-by: BuildkiteCI
2024-01-20 r/7425 fix(tvix/glue/benches/eval): add impure_builtinsFlorian Klink1-1/+2
Impure builtins need to be explicitly added. This was missed from cl/10640. Change-Id: I1f8a84aa02f1cf8a26247960d6eb15895e09c610 Reviewed-on: https://cl.tvl.fyi/c/depot/+/10667 Tested-by: BuildkiteCI Reviewed-by: raitobezarius <tvl@lahfa.xyz> Autosubmit: flokli <flokli@flokli.de>
2024-01-18 r/7411 refactor(tvix/glue): add BuildService to TvixStoreIOFlorian Klink1-0/+2
TvixStoreIO triggers builds whenever IO into a not-yet-built store path is requested, if it knows how to build that path. Change-Id: If30e9db6be2f2a30cbc9d0576f357f3ecfa0d35a Reviewed-on: https://cl.tvl.fyi/c/depot/+/10645 Reviewed-by: raitobezarius <tvl@lahfa.xyz> Tested-by: BuildkiteCI
2024-01-18 r/7410 feat(tvix/glue): use TvixStoreIO as derivation builtin stateRyan Lahfa1-12/+17
We propagate a `TvixStoreIO` as the `state` of our derivation-specific builtins in the glue crate. The evaluators `io_handle` itself is using a Rc<dyn EvalIO>. An earlier version of TvixStoreIO was also introducing generics over the different internal services themselves, but we opted for instead hardcoding this to Arc<dyn …> for the sake of less macro voodoo. Change-Id: I535c476f06b840858fa3070c4a237ece47f7a15b Reviewed-on: https://cl.tvl.fyi/c/depot/+/10636 Reviewed-by: raitobezarius <tvl@lahfa.xyz> Autosubmit: raitobezarius <tvl@lahfa.xyz> Tested-by: BuildkiteCI Reviewed-by: flokli <flokli@flokli.de>
2024-01-03 r/7338 feat(tvix/glue): contextful derivationRyan Lahfa1-10/+7
We calculate the input context by performing the union of context over all input of the derivation. Then, we just pass the rest of it to the remaining machinery. Finally, we re-emit an `outPath` and a `drvPath` containing the expected contexts. Change-Id: I74905fb258b5bee8b08d1208c9eb87f51b92a890 Reviewed-on: https://cl.tvl.fyi/c/depot/+/10436 Autosubmit: raitobezarius <tvl@lahfa.xyz> Reviewed-by: tazjin <tazjin@tvl.su> Tested-by: BuildkiteCI
2023-12-31 r/7289 refactor(tvix/eval): remove code and location from structFlorian Klink1-2/+2
Instead, it's passed in the evaluate/compile_only functions, which feels more naturally. It lets us set up the Evaluation struct long before we actually feed it with data to evaluate. Now that Evaluation::new() would be accepting an empty list of arguments, we can simply implement Default, making things a bit more idiomatic. Change-Id: I4369658634909a0c504fdffa18242a130daa0239 Reviewed-on: https://cl.tvl.fyi/c/depot/+/10475 Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su> Autosubmit: flokli <flokli@flokli.de>
2023-12-12 r/7161 feat(tvix/glue): add nixpkgs eval benchmarkFlorian Klink1-0/+68
This adds a criterion.rs-based testbench into tvix-glue. It can be invoked by running `cargo bench` from inside the `tvix-glue` crate. `target/criterion/report/index.html` contains nice graphs. It's able to diff against the previous run, so you can invoke `cargo bench` before and after a certain change to reason about the impact in evaluation performance. Currently, we need to create a bunch of Evaluator resources inside the benchmark loop itself, which is a bit annoying, as it leaks into the things we benchmark. This should become better with b/262. Fixes b/322. Change-Id: I91656a308887baa1d459ed54d58baae919a4aaf2 Reviewed-on: https://cl.tvl.fyi/c/depot/+/10245 Autosubmit: flokli <flokli@flokli.de> Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su>