Even when plugin discovery is cached, there's a separate database hit to retrieve the plugins when using the database cache backend.

Several plugins are used on every page request, so this can mean a dozen or more queries every request. This is a performance regresssion from info hooks, where the module_invoke_all() call would be quite cheap (except in certain cases).

Opening this issue to discuss whether we can optimize that - i.e. by using CacheCollector or similar.

Comments

Sylvain Lecoy’s picture

What about more generally store the configuration of plugins (and why not the plugin's configuration as well) in the container instead the database so by design the db layer is never needed?

catch’s picture

Because then you'd need to rebuild the container on every plugin configuration change, that could get quite messy I think.

yched’s picture

D7 info_hook based discoveries often involved an alter hook as well, and so AFAIK many of them had their own persistent caching - field types & widgets & formatters, views plugins... (less sure about ctools plugins)
So is this really a regression compared to D7 ?

Berdir’s picture

Berdir’s picture

@yched: See my issue, views alone has 11 different plugin types with a different cache that are loaded on every request (that displays a view). Quite sure that was a single cache in 7.x.

yched’s picture

[edit: right, crosspost]
Yeah, I guess the difference with D7 is that field types + widgets + formatters were stored in one single cache bin, while it's three different ones now.

catch’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)

I like Berdir's issue more, closing this as duplicate.