Opening this as a child of #2493035: Discover any memory limit issues we have → .
When submitting the modules page (no xdebug or xhprof), I see 70M of memory usage. We've just set core's minimum memory limit to 64M after lots of discussion (See #2289201-66: [Meta] Make drupal install and run within reasonable php memory limits so we can reset the memory requirements to lower levels → , so opening this as a critical bug.
The immediate worst offender I found was field_help(). This takes 800ms wall time on my machine, and 8mb of memory.
In ModuleListForm::buildRow() we check if the module has a hook_help() for the main help path - by executing hook_help() with that path. For field_help() this means listing every field type, widget and formatter - just to render a link. Needs an issue - we can probably move the actual listing to a dedicated route then link to it?
Other bad offenders:
views_theme() - loads lots of plugins. Not a new problem particularly - theme registry rebuilds have always been bad, but grrr. Worth an issue in case we can come up with something.
fileld_system_info_alter() 3.8M - should already have an issue.
filter_system_info_alter() 3M - should already have an issue.
Get the child issues RTBC and committed, then check the memory usage again.
Not here.
Not here.
Closed: outdated
9.5
Last updated
It affects performance. It is often combined with the Needs profiling tag.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
#2495087: comment_entity_storage_load() is too expensive on cold caches → is still open but we don't need this meta to track that.
📌 Add a cache prewarm API and use it to distribute cache rebuids after cache clears / during stampedes Needs work is new and attacks a lot of the same ground in a different way.