librelad c68254ad70 feat(lazy-load): dual loader with LP_LAZY=1 opt-in (Phase 3)
scripts/source/loading/initilize_files.sh gains an LP_LAZY=1 branch:
  - Sources scripts/source/files/arrays/function_manifest.sh once. The
    manifest defines LP_FN_MAP, LP_EAGER_FILES, AND ~700 autoload stubs
    (precompiled by the generator — one parse cost vs evaluating 700
    snippets at startup).
  - Eager-sources every file listed in LP_EAGER_FILES (top-level side
    effects: variable assignments, source calls, bare commands). These
    can't safely be deferred — they'd skip the side effect, not just the
    function definition.
  - Skips the bulk loop that sources every files_to_source[@] entry.

Default behaviour (LP_LAZY unset or 0) is byte-identical to the previous
loader — every file gets eager-sourced up front. Long-running processes
(WebUI service, task processor) leave LP_LAZY unset because their first
call to anything wants the function already hot.

Each autoload stub looks like:
  funcname() {
    source "${install_scripts_dir}path/to/file.sh"
    funcname "$@"
  }

First call sources the real file, which redefines the function with the
real body; the stub's trailing `funcname "$@"` then calls the freshly-
defined real implementation. Sourcing the file also redefines stubs for
any sibling functions the same file declares, so they don't re-source.

Safety nets:
- Missing manifest → fall back to eager loading (`export LP_LAZY=0`).
  No regression risk if someone enables LP_LAZY=1 on a stale install
  whose regen never ran.
- LP_LOAD_TRACE=1 still works in lazy mode — it records the manifest
  parse + each eager file (tagged LAZY-manifest / LAZY-EAGER) so Phase 4
  can measure the actual saving.

No automatic flip yet — this commit only adds the path. Phase 4 will set
LP_LAZY=1 by default for the CLI entrypoint (and re-measure with the
trace tool from Phase 1).

Signed-off-by: librelad <librelad@digitalangels.vip>
2026-05-26 20:51:24 +01:00
..