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 m Fix numbered list |
||
| 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 | ||