Improve attribute handling in RequestPredicates

[yuzawa-san]

I was doing some memory allocation flame chart analysis and found that there was a lot of copying of the attributes map in the AND/OR/NOT predicates which I believe can be avoided. The intent appeared to be to support the PathPatternPredicate which is the only implementation that updates the request state. Given that the PathPatternPredicate can be embedded within any number of boolean operators the save, evaluate, and restore operation was added in those predicates.

The solution I had was to introduce some additional classes which allow for the predicate to make changes. This is the Evaluation record which has the test result and whatever state changes should be done if the caller deems it so.

Open question: the PathPatternPredicate appeared to be the only implementation which updated the request, but do folks have state-modifying predicates out in the wild? It would appears physically possible, but at the same time against the @FunctionalInterface nature of the definition of RequestPredicate. So this could break extant use cases, but those use cases are not necessarily philosophically correct. Given PathPatternPredicate is internal (and "rule breaking" by changing state), I supposed internally we could support its rule breaking.

The existing RequestPredicateAttributesTests all pass still.

I only did the changes in webflux, but could port these changes over to the servlet functions as well later if this is accepted.

[poutsma]

Interesting. I will take a closer look for 6.1 M1.

[yuzawa-san]

@poutsma Thanks, here is some background. I have a few dozen routes registered like so:

RouterFunctions.Builder builder = RouterFunctions.route();
builder.add(RouterFunctions.route(RequestPredicates.GET("/foo"), fooHandler));
builder.add(RouterFunctions.route(RequestPredicates.GET("/bar"), barHandler));
....
return builder.build();

and I collected this memory icicle graph:

and this cpu icicle graph:

The saving and restoring uses the majority of the memory and cpu relative to the actual evaluation of the HttpMethodPredicate and PathPatternPredicate

My handlers dont use much cpu or memory, so this was constituting an non-negligible percentage of the applications overall footprint.

[yuzawa-san]

Here are some more extensive icicle graphs generated from my stress test.

memory before (the selected item is basically all of the "memory after" graph):

memory after:

cpu before:

cpu after:

and i have two more optimizations within that which should cut down even more: #30138 and #30139

[poutsma]

@yuzawa-san Great work, thanks!

[poutsma]

This PR has now been merged, though I did some refactoring and renaming.

Thank you for your contribution!