Skip to content
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

Evaluating the Nickel flake is very slow #1701

Open
thufschmitt opened this issue Oct 27, 2023 · 2 comments
Open

Evaluating the Nickel flake is very slow #1701

thufschmitt opened this issue Oct 27, 2023 · 2 comments

Comments

@thufschmitt
Copy link
Member

Describe the bug

Evaluating the default output of the flake takes a very long time (roughly 18s on my machine).
This is very annoying for projects like Organist that depend on Nickel by its flake as it adds a lot to their Nix evaluation time. And in the case of Organist, all the projects using Organist will have to pay for that.

The nickel derivation from Nixpkgs doesn't have this problem.

To Reproduce

$ nix run p#hyperfine -- -L FLAKEREF nickel\#default,nixpkgs\#nickel "nix eval {FLAKEREF}.outPath --option eval-cache false" --warmup 2
Benchmark 1: nix eval nickel#default.outPath --option eval-cache false
  Time (mean ± σ):     18.530 s ±  0.077 s    [User: 13.057 s, System: 2.872 s]
  Range (min … max):   18.363 s … 18.675 s    10 runs
 
Benchmark 2: nix eval nixpkgs#nickel.outPath --option eval-cache false
  Time (mean ± σ):      2.269 s ±  0.021 s    [User: 1.591 s, System: 0.415 s]
  Range (min … max):    2.239 s …  2.295 s    10 runs
 
Summary
  'nix eval nixpkgs#nickel.outPath --option eval-cache false' ran
    8.16 ± 0.08 times faster than 'nix eval nickel#default.outPath --option eval-cache false'

Expected behavior

Something fast :)

More seriously, I don't know whether that's something worth fixing since the evaluation time overhead is very likely due to Crane, and is hopefully repaid by a better build-time caching for iterative development. But it's worth being aware of it.

Environment

  • OS name + version:
  • Version of the code: 1921c31

Additional context

ø

@yannham
Copy link
Member

yannham commented Oct 29, 2023

In your opinion, what could be a way forward? Would adding an output nickel-fast that doesn't use crane make sense?

@thufschmitt
Copy link
Member Author

Honestly: I have no idea :)

For Organist, I've vendored a modified copy of the Nix expressions from Nixpkgs (here). If you're willing to maintain something like that then yes, exposing them as a nickel-fast output could make sense.

Otherwise, just saying that it's a price to pay for living at HEAD and that the releases get a fast expression from Nixpkgs would be a fine tradeoff for me. I was mostly opening the issue to make sure that you were aware that there's a tradeoff to make.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants