Memoization and option modules

hi there,

i had a nix question based on earlier comments on function calls preventing caching of results.

i was trying to understand what this means for writing performant nix code, but felt like i might not grasp the details here well enough.
for example, to DRY up some of the repetition in my code, I had tried to use functions to factor these out, which then sounds bad for performance.

i might then do away with such abstractions, but wondered if it gets better.
to make nix code reusable, for example, we may write option modules, which can essentially encapsulating any function calls so their consumer would not need to use those directly.

my question then is, might use of option modules help restore this ability to cache results?

1 Like

I think the performance impact of a function call is minimal in most cases, compared to the time saved having to not refactor things across a tree if you need to make a change to the behaviour. We can’t answer universally in the abstract.

Ultimately profiling is the answer. I only found Nix flamegraph or profiling tool? about this topic, though. But I will say, “performant” is relative, and if nixpkgs is involved, it will be slow. At best you can identify if there are major errors and correct those.

1 Like