This repository has been archived by the owner on Mar 11, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
Module System Performance
Robert Hensing edited this page Oct 6, 2022
·
2 revisions
Module system performance scales with the size of the application.
A small application of the module system is fairly quick to evaluate; similarly, submodules are evaluated quickly.
NixOS evaluation is a bit slow because it has a huge number of modules and options. This isn't necessary but not entirely trivial to change; see RFC 22 Minimal Module List. Refactoring the NixOS domain logic itself has benefits beyond performance; mostly improved flexibility to use only parts or replace parts.
- strictness induced by
attrsOf - strictness induced by the need to check for
mkIfs, causing the final value to be returned too soon - option trees are flattened, which might be inefficient, and might evaluate more option declarations than necessary in case of nesting
- constant factor impact of type checking
- constant factor impact of not-strictly-necessary but useful features like tracking option and definition locations (can we use more unsafeGetAttrPos?)