You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In particular the size of the nickel-res.json derivation. This gist contains code for the following dependency graph with variable depth, both created with native nix and organist. Evaluation of former seems to have the expected linear complexity, while for the one created with organist, it has exponential complexity.
This seems inevitable when we're passing the dependency graph from nickel to nix by serializing it to a tree with nickel export.
The text was updated successfully, but these errors were encountered:
That's indeed a limiting factor for scalability. There's some work on the Nickel side to add some experimental support for directly calling Nix from Nickel (though it's not good-enough for our use-case yet), that plus RFC 92 could hopefully sidestep this problem altogether eventually
In particular the size of the
nickel-res.json
derivation. This gist contains code for the following dependency graph with variable depth, both created with native nix and organist. Evaluation of former seems to have the expected linear complexity, while for the one created with organist, it has exponential complexity.This seems inevitable when we're passing the dependency graph from nickel to nix by serializing it to a tree with
nickel export
.The text was updated successfully, but these errors were encountered: