While studying the result of a profiling session of the Bean Validation benchmark with Marko, we noticed a few things:
* There's far too much time spent in {{LocalizedMessage#equals()}}. We thought about 2 things: interverting the 2 equals condition to test the message first: it's far more discriminating than the locale in most cases, and (maybe) try to avoid creating {{LocalizedMessage}} instances using a nested map (but the benefit should be measured, it's not obvious).
* {{ConstraintTree#mainConstraintNeedsEvaluation()}} can be tuned to test early if the {{constraintViolations}} set is empty.
* There is a lot of time spent in {{ReflectionHelper#getValue()}}. Maybe we could optimize things by storing the constraint per location in {{BeanMetaData}}, thus calling {{ReflectionHelper#getValue()}} only once per location, instead of calling it once per constraint.
* Less pressing (it's pretty low in the profile) but might be worth some investigation: {{ConstraintTree#passesCompositionTypeRequirement()}} appears in the profile whereas it's only useful if we have composing constraints (which is not the common case). Maybe we could try to have a fast path in {{validateConstraints()}} when we don't have any composing constraints. If the gain is very limited, it might not be worth it to complicate the code.
I also had a potentially interesting idea to reduce the cost of hashCoding the {{Path}}. We have a few nodes that have an invariant hashCode (considering that now the parent is not part of the hashCode anymore): at least bean nodes, return value nodes, cross parameter nodes.
Moreover if we moved the name at the end of the hashCode, we could also probably compute the property node hashCode from a static one + some calculations to add the name.
I would be curious to see if that buys us much. |
|
