## Summary I've been investigating `loopSummaries` and `loopImports` in the context of !15899 regressions. The code is (perhaps unnecessarily) complex in caches for how it manages previously seen modules and the worklist (which I think should deduplicate entries). It was unclear whether the cache was being propagated properly across all `loopSummaries` and `loopImports` so I traced the path to verify we never did create a `ModSummary` for the same module more than once. Well, for `MultiComponentModules100` the trace (with `sort | uniq -c | sort`) speaks for itself: ``` [...] 67 summariseModuleDispatch Top34 68 new_summary Top32 ... 90 new_summary Top10 90 summariseModuleDispatch Top11 91 new_summary Top9 91 summariseModuleDispatch Top10 92 new_summary Top8 92 summariseModuleDispatch Top9 93 new_summary Top7 93 summariseModuleDispatch Top8 ... 97 new_summary Top3 97 summariseModuleDispatch Top4 98 new_summary Top2 98 summariseModuleDispatch Top3 99 new_summary Top1 99 summariseModuleDispatch Top2 100 new_summary Top0 100 summariseModuleDispatch Top1 101 summariseModuleDispatch Top0 2100 summariseModuleDispatch GHC.Essentials 2100 summariseModuleDispatch Prelude ``` In `new_summary` we do three things mainly: preprocess the module (`preprocess`), parse its header from scratch to find imports (`getImportEdges`), `makeNewModSummary` (which calls `implicitRequirementsShallow`, a function which is notoriously very expensive (#27053) -- it calls `findImportedModule` for all the imports of the module we just parsed unconditionally) `new_summary` (`getImportEdges` + `getPreprocessedImports`) is about 50% of the total allocations in `MultiComponentModules100` (10GB/20GB)!! And we're calling it a non-linear amount of times in the amount of modules, **up to 100 times for a single module**, where all the work is being done from scratch. Here's a profile of `MultiComponentModules100`:  I intend to refactor and fix this. ## Environment * GHC version used: HEAD