PR ready on my side. A one-route app show no measurable performance impact. I'd be happy to gather performance number on real apps with bigger routing table.

Maybe @frankdejonge since you already worked on that topic? Anyone else really also :)

@nicolas-grekas I've anonymised the routes dump from the reference project I used. You can use this as a reference. I parsed it before to create the route collections: https://gist.github.com/frankdejonge/65e92a4bfa9e0daed6974e0a82ad0684

I would like to see benchmarks for both generating and matching here, as well as extensive testing that the new matcher behaves the same than the old one (as the logic is totally rewritten).

@stof out of curiosity, why would you want benchmarks for generating? The generation of the routes should be done before something is deployed and shipped in the artefact/container/deployable-zip/whatever. At least, that's my view on the subject, curious to hear what reasons you'd have to measure the performance of this.

@frankdejonge I think Christophe refers to generate a URL from a route ({{ path('my_route')) instead of generating these static files.

Ahhhhh that makes sense.

@nicolas-grekas did you see the gist with the routes?

Are we required to make this an abstract class forcing the child to implement RedirectableUrlMatcherInterface ?

Fixed

I would like to see benchmarks for both generating and matching here, as well as extensive testing that the new matcher behaves the same than the old one (as the logic is totally rewritten).

The code for the generator is exactly the same - only the initialization logic has changed - so I'm not going to spend much time on it.
For the matcher, I agree we're missing a test suite, too bad we didn't have it already.

The code for the generator is exactly the same - only the initialization logic has changed - so I'm not going to spend much time on it.

It would still make sense to have a benchmark to see whether we actually benefit from the static array caching.

For the matcher, I agree we're missing a test suite, too bad we didn't have it already.

It might make sense to work on building such testsuite first in a separate PR (which means it would run against the current implementation) and then rebase this PR on top of it (ensuring that the new implementation passes it too)

@frankdejonge your dump does not allow rebuilding the routes fully (requirements are not available in it for instance)

@stof in my case I just used a wildcard matcher because the changes didn't happen on that front. Doesn't seem to be a factor here either. The difference is the lookup mechanism, not those checks.

@frankdejonge as the matching logic has been fully rewritten, I would like to see benchmarks for cases using all features too, not only for a single case.

I've deleted the route dump. Have fun building feature complete fixtures

don't! it's no fun :)

Are we required to make this an abstract class forcing the child to implement RedirectableUrlMatcherInterface ?

Fixed - was easier than anticipated, this adds no overhead.

It would still make sense to have a benchmark to see whether we actually benefit from the static array caching.

the current code already benefits from static array caching, since it already dumps a static array - this is really 100% the same.

I did some benchmarks using one of my project routes (789 routes).
1000 revs, 3 iterations.
Winner is in bold.

PhpMatcherDumper vs StaticUrlMatcherDumper :

PhpGeneratorDumper vs StaticUrlGeneratorDumper :

UrlGenerator vs StaticUrlGenerator (each route is generated 10 times) :

@fancyweb benchmarking a dumper vs the other is irrelevant. Dumping happens during cache warmup, where we can spend time.

What we need is to compare the matching using the dumped matcher vs the matching using the static matcher with dumped routes. And this is what you don't have in your comment.

@fancyweb: @stof is right, sorry if that wasn't clear enough. The perf comparison should be about both url matchers: the one generated by PhpDumperMatcher, vs a StaticUrlMatcher one.

Since bootstrap time should be considered, I think the way to bench this is taking a skeleton, load it with some fixture routes, and measure the response time before/after this PR.

Matcher now tested, with the existing test cases from UrlMatcher.

As far as I tested correctly, on PHP 7.2, this is slower by a very tiny margin. The reason is easy: the matching loop has to do extra "ifs". But the difference does not diverge and is barely measurable in practice, both on small and big tables. Which means I did not hit the theoretical scalability issue with the current code. One might want to try with bigger tables (mine had ~1000 routes).

From design pov, I prefer a generic algorithm with data driven input than a dumped code. So I'm still on the side that this should be seriously considered. E.g. by looking at the data, we can already see that there are more potential optimizations that could be driven by creating hash-maps (a lot of routes could be just put into hashes and don't require the "strpos" check beforehand. Doing so at the code generation level is possible, eg using a switch on PHP 7.2, or inline hashes. But working at the data level is much more comprehensible IMHO.

The last benefit of this approach is the name of the router, which is stable. This can also be achieved in the code-generation approach, by dumping an anonymous class, now that we can use them.

I feel like this new method allows optimizations in a way the old one did not. Instead of deprecating the current, can we simply add this new compilation under a feature flag (for now), and try to optimize it before 4.1 is released? If it turns out we can't get it faster, we can always drop it before 4.1.

If it turns out we can't get it faster, we can always drop it before 4.1.

that's true even if we keep the existing approach. Until the RC release, we are free to drop this new class and undeprecate the old one if we decide to do it.

we can already see that there are more potential optimizations that could be driven by creating hash-maps (a lot of routes could be just put into hashes and don't require the "strpos" check beforehand. Doing so at the code generation level is possible, eg using a switch on PHP 7.2, or inline hashes. But working at the data level is much more comprehensible IMHO.

I'm not sure this holds true considering that the order of routes is important (as soon as a route has a dynamic part, it limits optimizations for any subsequent routes). And even if we find a way to rearrange routes to optimize them (figuring out that we can switch routes because their matching is totally exclusive and so the order does not matter), such rearranging would then be usable with the dumped class too, not only with the dumped array.
This makes me think that working on re-arranging routes to unlock more optimizations might be more useful than a rewrite of battle-tested working code.

And in practice, my project has 589 routes (including the WebProfiler ones as this is in dev), among which 439 have placeholders (and so cannot be catched by a map). This lives 150 routes which could be matched by a hashmap lookup (and I think a re-arranging can move them all at the beginning given my URL convention and the fact that my requirements and route order are strict enough to avoid any ambiguity). So the re-arranging might be worth it (it is required for any useful hashmap lookup, as these 150 routes are spread over the full list, with dynamic routes appearing early (the _wdt one is even first).

For people wanting to perform a similar analysis, here is what I used as commands:

• counting routes: bin/console debug:router | grep ANY |wc if you don't use the scheme requirement or the host requirement (and so all routes have ANY for them). Otherwise, run bin/console debug:router |wc and substract 5 for the output lines not being routes (table header and table delimiters)
• counting dymaic routes: bin/console debug:router | grep '{' |wc

As far as I tested correctly, on PHP 7.2, this is slower by a very tiny margin. The reason is easy: the matching loop has to do extra "ifs". But the difference does not diverge and is barely measurable in practice, both on small and big tables. Which means I did not hit the theoretical scalability issue with the current code. One might want to try with bigger tables (mine had ~1000 routes).

This makes me think that your promise (in the PR description) of making the router scaling to a higher number of routes is actually not true, as there is no performance difference.

I know for a thing that sorting routes will mess up a lot, but if it means performance, I'm sure I could change my routes to not be messed up. However, there will always be some fallback routes (like wildcard /.*) that need to be done last.

It almost sounds like a proper tree should be build and visualized so developers can detect url problems and probably optimize by using certain urls.

I'm closing because this demonstrated to me that this cannot be faster: traversing the static array is always going to be slower than loading + traversing the opcodes.
The implementation is finished so that if someone wants to borrow it in situations where dumping code is not possible, it's still possible.

@iltar this is why I'm talking about reordering routes as an optimization when we can be sure they are exclusive (and so their order does not matter).

And when working on implementing such logic, building a debugging tool visualizing it might indeed make sense.