3

I am working with clash (haskell -> verilog) compilation the demo project at https://github.com/mheinzel/clash-yosys-demo provides both a nix branch and one using stack.

running

time clash -v --verilog src/Top.hs -outputdir build

takes

  • ~ 1m if I run it inside a nix shell, compared to
  • ~ 2s if I use the version I installed with stack install --resolver lts-12.12 clash-ghc

I am very much a Nix beginner and using Nixpkgs, so can anyone give me pointers where to look at why my Nix environment version is so much slower? It seems the linking of used libraries is taking ages (this is what I got from using -v, the verbose flag).

toraritte
  • 6,300
  • 3
  • 46
  • 67
epsilonhalbe
  • 15,637
  • 5
  • 46
  • 74
  • 1
    I'd reach for `sysdig` for this analysis, to get a trace of what's going on in-process. This isn't a general nix problem -- it may be specific to clash or some other particular tooling, but one really needs to run it down a bit more to ask a better-focused question. – Charles Duffy Jul 15 '22 at 17:19
  • I’m voting to close this question because the link is dead (the repo it points to has also been deleted since) so it does not have a minimal, reproducible example. However, this is a perfectly valid and relevant question, and could be turned into a more general one as this issue is not specific to Haskell, Clash, or any particular software or package, but to the Nix derivation language and/or how Nix works. (See e.g.,, https://discourse.nixos.org/t/why-does-nix-shell-take-so-long/8530) – toraritte Jul 15 '22 at 17:19
  • @toraritte, that link is about _starting_ a nix-shell instance, this question is about running a compilation process one inside one after it's already done being invoked. I'm not at all convinced that they're topically similar. – Charles Duffy Jul 15 '22 at 17:20
  • @CharlesDuffy Isn't the mechanism the same? I'm genuinely interested as I found this question while researching to ask a similar one about `nix-shell` being slow (here and/or on discourse). I also voted to close this question because it may be impossible to answer it without looking at the scripts themselves - I'm far from being a Nix expert though so I may be absolutely wrong... (anyway, still edited and upvoted it) – toraritte Jul 15 '22 at 17:27
  • @CharlesDuffy Just out of curiosity: how did you come upon this thread at this exact same time when it has been open for 3 years?:) – toraritte Jul 15 '22 at 17:27
  • 1
    @toraritte, when you edited that bumped it to the front page. – Charles Duffy Jul 15 '22 at 17:34
  • 1
    @toraritte, ...that said, re: "isn't the mechanism the same?" -- I'm not sure I follow. Building something like a `pkgs.mkShell` derivation requires compiling everything going into that derivation, but once the derivation is built and you've activated the shell, then for the most part it's acting like any other process; you've got rpath-based dynamic linking, a long `PATH` variable, and some other changes that _do_ impact runtime performance, but that's very different from the performance of the process of building the derivation and its dependencies, and it's the latter covered in the link – Charles Duffy Jul 15 '22 at 17:37
  • 1
    (and _normally_, the time spent in `PATH` lookups and the like is trivial, so the runtime performance penalty from doing things the Nix way ends up being unnoticeable except in microbenchmarks designed to stress it; thus, one usually ends up with a significant build-time penalty but an unnoticeable runtime one). – Charles Duffy Jul 15 '22 at 17:41
  • @CharlesDuffy Wow, thanks for this! Will need to digest it, but at least my ignorance is exposed. Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/246478/discussion-between-toraritte-and-charles-duffy). – toraritte Jul 15 '22 at 17:44
  • (The [archived version of the chat](https://web.archive.org/web/20220715182254/https://chat.stackoverflow.com/rooms/246478/discussion-between-toraritte-and-charles-duffy) as they have a tendency to disappear.) – toraritte Jul 15 '22 at 18:25

0 Answers0