Performance regression in menu access checks

Pretty sure these are running Several times in the path based breadcrumb builder, applying the route enhancers each time too

In drupal6 the l/url function had a possibilty to disable path alias aka. path processors. I wonder whether we might could apply this to some performance relevant places.

Another idea was once to put some of the html routes in a optimized frontend router, which can match things like node/{node} way faster, maybe even in php directly without the involvement of a database. I don't know the issue anymore, but there was some serious work already which dumped some route matcher to a php file.

#2047633: Move definition of menu links to hook_menu_link_defaults(), decouple key name from path, and make 'parent' explicit seems to fix the majority of needless invocations to menu_item_route_access(); however, some remain. For example, for a front page, it gets invoked via the call to menu_set_custom_theme() in LegacyRequestSubscriber::onKernelRequestLegacy(), and also by _menu_get_legacy_tasks().

I suggest we first get rid of all such legacy / unnecessary callers.

If we're left with enough legitimate callers (e.g., path based breadcrumb builder, though I question the ultimate legitimacy of that one as well), we can figure out how to optimize based on what those use cases actually need vs. not.

Quoting myself from #2019123-64: Use the same canonical URI paths as for HTML routes:

it's insane for us to call matchRequest() for anything other than the one actual HTTP request being handled (not counting non-performance-critical steps, like saving a menu link or rebuilding menu caches)

Basically, wherever we're calling matchRequest() other than that is a situation where we only have a path, but really should have a route already, or are doing something silly like what menu_item_route_access() does and turns a route back into a path in order to have all the fun of trying to match it back to a route. For that case, we ought to be able to just use the route and route parameters we already have, and invoke ParamConverterManager directly without doing it via a full matchRequest(). However, per #4, I don't know that it's worth trying to make that change prior to finishing #2047633: Move definition of menu links to hook_menu_link_defaults(), decouple key name from path, and make 'parent' explicit and possibly some of the other legacy flows.

it gets invoked via the call to menu_set_custom_theme()

Removed in #1954892: Replace 'theme callback' and hook_custom_theme() with a clean theme negotiation system

.

Basically, wherever we're calling matchRequest() other than that is a situation where we only have a path, but really should have a route already, or are doing something silly like what menu_item_route_access() does and turns a route back into a path in order to have all the fun of trying to match it back to a route. For that case, we ought to be able to just use the route and route parameters we already have, and invoke ParamConverterManager directly without doing it via a full matchRequest(). However, per #4, I don't know that it's worth trying to make that change prior to finishing #2047633: Move definition of menu links to hook_default_menu_links(), decouple key name from path, and make 'parent' explicit and possibly some of the other legacy flows.

This is a perfect description for a piece of code we do already have in core: https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Access!AccessMana...