Performance considerations of the EntityView module

[david-kubecka]

I'm curious about various performance aspects of EntityViews. I tried to at least skim through most parts of the documentation (deep diving into some sections) but I couldn't find much relevant info. I guess the performance aspects derive from the architecture but the description is quite high level so I'm rather asking explicitly. Basically, I would like to get a comparison of the EntityView approach to the "baseline" design. That is:

• Spring Data JPA with Hibernate as a provider
• converting entities to DTOs on service/controller boundary

The aspects can be broadly divided into 3 categories. I'm kicking off some questions that come to my mind. Please add anything else which you might find relevant.

Compile time

E.g. Is there a significant overhead of the annotation processor? (that is compared to the baseline setup)

Anything else?

Boot time

Here I guess there's the extra initial @EntityView scanning which might significantly prolong start-up time. I've seen some past issues and improvements in this area, though. What's the current status? Any future developments planned here (or at least ideas for improvement)?

Anything else?

Runtime

I'm especially interested in how reflection is used to populate entity views and how this compares to the baseline approach. My understanding is that entity views are similar to DTO projections, i.e. they bypass actual entity creation and so they shouldn't be worse reflection-wise than the baseline approach.

Anything else?

Many thanks in advance for your reply!

[beikov]

Compile time
E.g. Is there a significant overhead of the annotation processor? (that is compared to the baseline setup)

Obviously, the annotation processor comes with some overhead as it has to analyze entity view classes and generate code for them, but the overhead should be negligible compared to the overall compilation process. Apart from that, you can also skip annotation processing if you prefer generating classes at boot time.

Boot time
Here I guess there's the extra initial @EntityView scanning which might significantly prolong start-up time. I've seen some past issues and improvements in this area, though. What's the current status? Any future developments planned here (or at least ideas for improvement)?

The scanning in a Spring or CDI project might incur some overhead, but I have never heard of this being a problem in real apps. In Quarkus projects, scanning happens in the "deployment phase" which runs during application packaging, which is more like compile time than boot time.

We could improve the scanning a bit with Jandex, but I'll only start looking into that if it really becomes a problem for someone who can actually show me a project where this is reproducible. If this becomes an issue for you, you could also disable scanning and write a class that registers all entity view classes to the configuration.

Apart from that, the whole metamodel is built at boot time, which we could also build in parallel if necessary, but that also hasn't been an issue for anyone so far.

If you don't use the annotation processor, depending on configuration, the entity view implementations are generated at boot time or on first use.

Runtime
I'm especially interested in how reflection is used to populate entity views and how this compares to the baseline approach. My understanding is that entity views are similar to DTO projections, i.e. they bypass actual entity creation and so they shouldn't be worse reflection-wise than the baseline approach.

The only reflection part that happens during runtime is for instantiating the entity view objects. If this turns out to be a provable bottleneck for someone, we can also generate bytecode factories to speed things up, but if you look into the implementation, you will notice that it is very efficient already, also from an algorithmic perspective.

What happens from a high level view is this:

1. Get cached ViewTypeObjectBuilderTemplate
2. Apply that template to a CriteriaBuilder
   2.1. Do individual select() calls for all select items
   2.2. Register a ViewTypeObjectBuilder

Then, when you execute the query:

1. Hibernate constructs an Object[] for the select items for every row. It always does that, also for entities.
2. For every result element, the ViewTypeObjectBuilder is called which transforms the data to entity views and nested collections
3. Finally, the ViewTypeObjectBuilder is called for the whole list to also do a final reduction of the result list, to match the expected cardinality

Overall, the actual code that runs should (1) in the simple cases be very similar to what you would write yourself, and (2) in the non-trivial cases be a lot more efficient due to special internal data structures and various optimizations.

Hope that helps you understand what is happening behind the scenes.

[david-kubecka]

Thank you for your elaborate answer!

If I would like to debug a perceived framework performance issue, what would be the best way to do that? By setting log levels for specific classes/packages, for example?

[beikov]

First, I would try to find out how many and how long queries run. If you have too many queries, you'll have to fix that in your app somehow. Hibernate has a slow query logging config for detecting slow queries. As soon as you understand the performance problem of a query, you can start tuning.

• Create indexes or statistics, depending on the query plan
• Alter the query e.g. by using different FetchStrategy in entity views for problematic parts. Also see the documentation

If the problem is not a single query and you think that it is a problem of the framework code, you should run the async profiler and produce a flame graph to understand where the most time is spent in the framework. You can submit that flame graph through a GitHub issue and someone will look into it.

[david-kubecka]

Sorry, I should have been more specific. By debugging framework perf issues I mean the infrastructure parts (the main topic of this issue), i.e. especially boot and runtime. I wonder whether BP already provides some log events to help achieve that (or a different method).

[beikov]

It doesn't provide any logging based mechanism, no.

[david-kubecka]

Ok, hopefully I won't ever need to investigate such issues :-)