Optimise evaluation time?

[L-as]

Evaluating the derivation of a haskell.nix project seems to take a very long amount of time even if every IFD has already been built. Maybe more processing could happen "inside" the IFD, so that more can be cached?

[ocharles]

On this I've seen next to no change in evaluation time with materialization. I dunno if that warrants a separate issue

[L-as]

"next to none" I assume, indeed, this is about the non-materialised case, but this should still be blazing fast, and not take ~10 seconds.

[L-as]

I just counted, and with a Ryzen 5 1600, it took ~15 seconds to do nix develop, without building anything!

[ocharles]

Sorry, I was saying that for me, evaluation times with materialization are exactly the same as materialization times without materialization.

[michaelpj]

We've observed this recently too, and we've actually dropped materialization in some projects for that reason. Unclear why though, it still seems like it should be a speedup!

Unfortunately, analysing the performance of Nix code is pretty difficult, I don't believe there's really anything like a profiler.

[L-as]

@michaelpj Just moving the evaluation into a derivation and import-ing it seems like an easy hammer to use.

[hamishmack]

This has been bugging me for a while.

Could it be related to the size of hackage.nix? One simple test might be to take hacakge.nix and strip out all the packages a slow project does not use. Then see if the project is still slow.

Is it how we use the module system for modules? I'm not sure how best to test this. The last time we looked the profiling tools in nix did not help (but I think that was about 2 years ago).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kokobd]

I find this still relevant. Can we reopen this, and document that materialization no longer provides significant improvements if we are not going to fix this soon?

[enobayram]

Hi everyone, we were suffering from the same evaluation time performance issue, especially in Nix projects that gathered multiple haskell.nix-built projects together. We've ended up using recursive-nix to address this issue. See this comment for more details.

[L-as]

Very brave to use recursive-nix in production!

[enobayram]

@L-as would you care to elaborate on that point? I understand how recursive-nix is at odds with many assumptions made by various parts of the Nix tooling, but as far as I can tell, wrapping flakes this way is a sound way of using it since flakes enforce purity. In fact, I don't understand why we still don't get this kind of caching for flake outputs out of the box. Anyway, I wanted to share this as a practical workaround for a lack a crucial feature Nix should've been providing us.

You're free to remain snarky of course, after all we're living through a bleak period of the Internet history tainted with the vitriol eruption of influencers and Twitter engagement farming.

[L-as]

@enobayram it's not meant as snark, it is because it truly is experimental, unlike flakes which are merely experimental in name. Recursive Nix isn't well maintained and was buggy last time I tried it IIRC.