Nix Evaluation Performance: Difference between revisions
imported>Infinisil Correct mistaken explanation regarding referenced variables; Nix wouldn't evaluate the original expression multiple times if variables were to create new thunks |
imported>Infinisil mNo edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 24: | Line 24: | ||
#: This means that when you see e.g. <code>"hello"</code> or <code>true</code> in Nix, you know that Nix won't allocate a thunk for that. The reason for this is that there's not much to evaluate there, putting it into a thunk wouldn't make much sense. | #: This means that when you see e.g. <code>"hello"</code> or <code>true</code> in Nix, you know that Nix won't allocate a thunk for that. The reason for this is that there's not much to evaluate there, putting it into a thunk wouldn't make much sense. | ||
#: Note however that this is ''not'' the case for <code>"Hello ${name}"</code>, because that is desugared to <code>"Hello " + name</code> underneath, which won't be a string by itself anymore | #: Note however that this is ''not'' the case for <code>"Hello ${name}"</code>, because that is desugared to <code>"Hello " + name</code> underneath, which won't be a string by itself anymore | ||
# Nix won't create thunks for referenced variables | # Nix won't create thunks for referenced variables | ||
#: This means that once you defined a variable in a <code>let in</code> expression, or you're in a function that received some arguments at the top, Nix won't create extra thunks for when you reference these variables. | #: This means that once you defined a variable in a <code>let in</code> expression, or you're in a function that received some arguments at the top, Nix won't create extra thunks for when you reference these variables. | ||
#: It makes a lot of sense for Nix to do this, because variables themselves already point to either a thunk or an evaluated value, which can be used directly and doesn't need to be wrapped in another thunk that would just say "Evaluate this variable". | #: It makes a lot of sense for Nix to do this, because variables themselves already point to either a thunk or an evaluated value, which can be used directly and doesn't need to be wrapped in another thunk that would just say "Evaluate this variable". | ||
# The following expressions attempt to create thunks if allowed by above two rules | # The following expressions attempt to create thunks if allowed by above two rules | ||
#* <code>let in</code> expressions attempt to create a thunk for each variable | #* <code>let in</code> expressions attempt to create a thunk for each variable | ||
| Line 142: | Line 140: | ||
=== Using Thunks to Your Advantage === | === Using Thunks to Your Advantage === | ||
TODO: Explain how to use thunks to avoid duplicating work. | TODO: Explain how to use thunks to avoid duplicating work. Often it makes sense to move let bindings out as far as possible, but sometimes that can even cause extra thunks to be allocated. Show how attribute sets or lists can be used for memoization. | ||