Field-level constraint performance impairment

Description

Using Hibernate Validator to validate all Strings fields in an entity as we pull data from our Oracle database.

There is a significant slow down when performing field-level validation on a collection of entities with multiple field constraints.

While retrieving ~72,000 entities from the database, each with 8 constraints, it takes 47 seconds to perform validation (only 3 seconds to retrieve data from the database).
Using only custom constraints and using only built-in constraints (@NotNull) show the same performance issue.
Some debugging shows that 46.5 seconds is spent after calling Validator.validate() and before reaching isValid().

However, when setting the annotation at class-level, manually performing the required reflection and string validation on the entity inside isValid(), it only takes 0.5 seconds to complete validation for all 72,000 entities.

Hibernate should be able to naively handle this magnitude of field-level validations without resorting to manual validation at a class-level.

Environment

Hibernate Validator 5.1.3
EclipseLink 2.5.2
JPA 2.0
JDK 1.7.0 u65

Activity

Show:
Andre Hernandez
December 17, 2015, 5:17 PM
Edited

Nevermind the entities, JPA, and custom constraints. This issue can be seen using normal beans with built-in validators.
Working on getting you a test case. You'll have to bear with me, as I have to set this up from scratch (including my solution) on a new system.

This is an example of how we are calling the validator:

That one is interesting, why do you use reflection in your class-level constraint? I'd expect you could access the entity state via normal field/getter accesses?

Shown in the code above, we have a method that can take any bean class, and we have over 500 different bean types that can be passed.
I've attached an example bean using built-in validators.

Andre Hernandez
December 17, 2015, 9:41 PM

I attached a test case.
I have yet to look at the HV source code.
That being said, my solution is for my specific use case and might not be the solution to increase all field-level performance.

Although the performance gain is not as drastic as seen when handling entities, there is still ~25% gain when handling regular beans.
In the test case, I use ValidationService to handle class-level validation, and perform validation only on the required field-level annotations.

Hardy Ferentschik
December 18, 2015, 9:05 AM

Looking at your code, it is indeed very specific. You really only do what is necessary for your particular use case. In Hibernate Validator you need to deal with a generic approach and you will need to do metadata creation and caching, ConstraintValidator resolution, message interpolation, call to traversable resolver, etc. I don't really see how this is directly comparable.

I have yet to look at the HV source code.

Sure, any additional pair of eyes are welcome. Really to make any improvements as part of this issue, we would need to pin point some concrete problems in the Validator code. There are probably many things which can be improved.

Although the performance gain is not as drastic as seen when handling entities, there is still ~25% gain when handling regular beans.

I am a bit confused here on what you are saying? When you say entities, do you mean JPA entities opposed to plain Pojos? If so, there will always be a difference. In the context of JPA, you need to call as per spec the TraversableResolver as well. That adds another overhead. So what are you really saying here? That using your custom solution is ~25% faster for plain Pojos than using Hibernate Validator? If so, that would not be so bad imo.

Guillaume Smet
October 25, 2017, 11:50 AM

I added a Maven project with the OP's benchmark.

Guillaume Smet
October 25, 2017, 11:58 AM

Results with 5.1.3.Final (version used by the OP)

Results with 5.4.2.Final (last 5.x version)

Results with my current 6.0.4-SNAPSHOT

So the situation was quite worse in 5.4 than it was in 5.1. It's now much better in 6. We still have some overhead but we also do a lot more operations when dealing with fields so it's quite normal.

We might be able to make further improvements in the future but for now I think we can mark this issue as resolved.

Assignee

Guillaume Smet

Reporter

Andre Hernandez

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Components

Fix versions

Affects versions

Priority

Major
Configure