From 8f02e95aff2b9cb94470ec379e2a3f55858cb03d Mon Sep 17 00:00:00 2001 From: Robert Hensing Date: Sun, 16 Apr 2023 19:44:18 +0200 Subject: [PATCH] module-system.chapter.md: Elaborate on extendModules performance --- doc/module-system/module-system.chapter.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/doc/module-system/module-system.chapter.md b/doc/module-system/module-system.chapter.md index 2f9716c89dbc..9a24ab70c6c1 100644 --- a/doc/module-system/module-system.chapter.md +++ b/doc/module-system/module-system.chapter.md @@ -75,11 +75,20 @@ A function similar to `evalModules` but building on top of the already passed [` If you're familiar with prototype inheritance, you can think of the current, actual `evalModules` invocation as the prototype, and the return value of `extendModules` as the instance. +This functionality is also available to modules as the `extendModules` module argument. + +::: {.note} + +**Evaluation Performance** + +`extendModules` returns a configuration that shares very little with the original `evalModules` invocation, because the module arguments may be different. + +So if you have a configuration that has been (or will be) largely evaluated, almost none of the computation is shared with the configuration returned by `extendModules`. + The real work of module evaluation happens while computing the values in `config` and `options`, so multiple invocations of `extendModules` have a particularly small cost, as long as only the final `config` and `options` are evaluated. If you do reference multiple `config` (or `options`) from before and after `extendModules`, evaluation performance is the same as with multiple `evalModules` invocations, because the new modules' ability to override existing configuration fundamentally requires constructing a new `config` and `options` fixpoint. - -This functionality is also available to modules as the `extendModules` module argument. +::: #### `_module` {#module-system-lib-evalModules-return-value-_module}