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
John O'Hara also mentioned that the constraint per location in {{ BeanMetaData}}, thus calling {{ReflectionHelper CollectionHelper # getValue newHashMap ()}} only once per location, instead of calling it once per constraint.
* Less pressing (it's pretty low call in the profile) but might be worth some investigation: {{ ConstraintTree ValidatorImpl # passesCompositionTypeRequirement validateConstraintsForDefaultGroup ()}} appears in the profile whereas it's only was preventing some useful if we have composing constraints (which is not the common case) compiler optimization . Maybe we could try to have a fast path in {{validateConstraints()}} when we don Let ' t have any composing constraints. If the gain is very limited, s get rid of it might not be worth as 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 has no 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. |
|
