Quering the database for router items is slow (access checking)

This query is loading based on an indexed key so should actually be a lot faster than what we would do in Drupal 7:
https://api.drupal.org/api/drupal/includes%21menu.inc/function/menu_get_...

Note that we can already load multiple routes in one call, and in some cases, like Local Tasks, we are pre-loading via a multi-load so that we hit the database only once regardless of how many tabs are being displayed.
see:
#2032311: Load all routes for local tasks via getRoutesByNames()

I think this issue overlaps with Crell's idea that we should have a small set of very commonly used routes potentially dumped to PHP and in memory all the time. A first pass of this could be all the entity routes, and maybe the front page, 403, and 404 pages.

@catch - yes, we can mitigate that by loading all the needed routes in one call as the linked patch does, but I would much, much rather have a system like tagging some routes to be dumped to PHP for speed than trying to implement yet more caching.

This patch does similar for local actions #2077473: Replace local action plugin discovery with YamlDiscovery and handle routes with parameters

As there is code all over the place which deals with the "router.route_provider" service directly we could not use the concept of the chained router but would
also have to do something like a chained route provider.

For menu links there is already #2058845: Pre-load non-admin routes which can do that loading.

While talking with lukas smith we realized that Drupal should not pass around the url generator but the chained router, which wraps the generate method so you don't have to use a separate fast route provider but all you need is to rely on the fast router itself.

Battle plan: Allow to tag routes. Once they are tagged they are compiled to PHP.
This php is used together with a static route from symfony.

Additional we have to bring our new url generator interface to the chained router (both the interface and the actual implementation)
and never use the url generator directly.

Do you have an idea how you'd handle the tagging?

We could check that tag on our route builder, collect the routes and then use the phpmatcherDumper from symfony.

Sorry I get that bit - I mean what to name the tag, what the criteria would be for tagging.

A tricky one for tagging is Views routes - some of them are admin/*, another might be the front page or taxonomy/term/*, unless that's an option in the UI.

I guess the criteria should be rather less aggressive but people can retag them later.
What about everything which is not accessed read only and is not in the administration interface, so node/{node} would be in there, but node/{node}/edit won't be.

Did some work to compile the node edit route using the php storage system with a lot of help from chx.

Sadly it does not work so let's not torture the testbot.

This works now beside the fact that the symfony php dumper is broken, as it does not export options neither the requirements or anything similar.

Some work done:

• Add a static router which uses the dumped url matcher as well as a new dumped url generator
• Problems still: The dumped classes do not contain the full route object, which we need in order to actually solve the problem.

I think node/{node}/edit should be, since we often render that tab.

I'd tag most entity routes (node, taxonomy, user) as a start.

To be honest we should really keep in mind that adding something here adds a potential overhead for every page.

You mean overhead? :)

Yeah as written ;)

let's see if the tests run.

I'm not sure what the dumped file looks like, but how many routes do we think will be there? maybe 20?

Sees like the overhead of loading one extra file (I assume opcode cached) would be less then the DB queries?

The generated code basically does look like the follwing, so even the order of execution potential matters.

  function match($path) {
    if ($path == 'node') {
      return array('route' => 'views.node.page_1');
    }
    elseif (preg_match('...)) {
      return array('route' => 'node_view');
    }
  }

I'm a bit with beejeebus. If we think there is a subset of core routes that are often used OOTB, let's just have a hand-built matcher that handles those as efficiently as possible.

I think we should postpone this until we actually have the all the route conversions done, since this is something we can add pretty late with no API change (other than you'd have to e.g. hack core to change the node path patterns).

For some very simple and very common routes (like the 2-3 that are currently called on nearly every page load, like the toolbar), we can also look into just hard coding some logic into a request listener to call the controller, create a response, and set it. That way we bypass routing entirely. It won't work for everything (probably not for any HTML pages), but for maybe a half-dozen really-simple routes (ajax requests and the like) it could be worthwhile.

@Crell - is there a real advantage vs a set of dumped PHP routes? It feels like that could be broader and more flexibly and at least would fall within the same paradigm as the rest.

We'd have to benchmark that to know; I couldn't say off hand.

The other advantage of it is that every time I drop a break point on the cufa() in HttpKernel to call the controller, it always gets picked up at least 3 times since there's 2 extra HTTP requests. So short-circuiting the every-page requests would have a DX benefit, too.

Edit: To be clear, I'm not against PHP-dumping common routes at all. I'm saying that there's another alternative that may work in some specific circumstances.

With the introduction of the middlewares people could do a way faster routing, if they want, especially if you know that you don't need upcasting.
You could bypass access checking and what not.

Tagging.

Caching the access result could be quite tricky, but we could at least cache the query in RouteProvider itself, that would replace the database query there by default with some cache.

Added a couple of related issues, which at least one tried to do the exact same thhing (potentially cache parts ...)

Caching the access result could be quite tricky, but we could at least cache the query in RouteProvider itself, that would replace the database query there by default with some cache.

Added a couple of related issues, which at least one tried to do the exact same thhing (potentially cache parts ...)