Add benchmarks that include some HTTP method matching.
Clean up names and name like-kinded benchmarks alphabetically.
Matcher*Benchmark -> E2E including HTTP method selection
MatcherSelectCandidates*Benchmark -> Focused on just URL path processing
* Introduce RoutePattern
Introduces RoutePattern - a new parser and representation for routing
templates, defaults, and constraints.
This is a new representation for all of the 'inputs' to routing that is
immutable and captures 'out of line' information for defaults and
constraints.
This will allow us to unify the handling of constraints and values from
attribute style routes and conventional style routes.
This is a code dump of existing tests for TemplateMatcher and TreeRouter
converted to the format of matcher conformance tests.
Note that most of the new tests aren't yet supported by our experimental
matchers, which don't support many of these advanced features.
The instruction matcher was missing a few details, which made it faster
than it should have been. Right now I'm trying to keep the design of
these in sync. Once I fixed that it exposed a legitimate bug that was
blocking the github benchmark.
This change improves this area a bit by consolidating the matcher
implementations between the benchmarks project and the conformance
tests.
Additionally I split the minimal matcher into a really trivial
implementation for the simple tests and a more complex one for the
larger tests. This allows us to keep the plaintext/techempower scenario
in sight while also having a good baseline for the more sophisticated
tests.
Also starting to add tests that verify that matchers behave as expected.
The matchers now successfully execute all of these benchmarks, which
means that they support literals and parameters.
Missing features:
- complex segments
- catchall
- default values
- optional parameters
- constraints
- complex segments with file extensions
This is a good place to iterate a bit more of perf and try to make a
decision about what we want to implement.
This change adds the Template as a top level abstraction. URL templating
is now a two-stage process.
First you use a 'key' to look up a Template, then you use the Template
to create the URL.
This change also has some cleanup of the way RoutePatternBinder gets
instantiated. I added a factory service so that most of the complex
things can be made internal to Dispatcher. Now it's much easier to
constuct and use. These impacts some pubternal APIs that we already
broke, but makes them actually nice :)
Also cleaned up some tests and fixed one that was broken and not
running.
-Renamed RouteTemplate -> RoutePattern
-Made immutable
-Added Builder
-Lots of fixes to parser to support new design
There are a few small issues logged for follow-up but this is mostly in
the place I want it design-wise.
Kiran Challa
Kiran Challa
Ryan Nowak
James Newton-King
Nate McMaster
Ryan Nowak
kishan.anem
=
Jass Bagga
Pranav K
Joonas Westlin