Why are interface projections much slower than constructor projections and entity projections in Spring Data JPA with Hibernate?
Asked Answered
P

2

38

I've been wondering which kind of projections should I use, so I did a little test, which covered 5 types of projections (based on docs: https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#projections):

1. Entity projection

This is just a standard findAll() provided by Spring Data repository. Nothing fancy here.

Service:

List<SampleEntity> projections = sampleRepository.findAll();

Entity:

@Entity
@Table(name = "SAMPLE_ENTITIES")
public class SampleEntity {
    @Id
    private Long id;
    private String name;
    private String city;
    private Integer age;
}

2. Constructor projection

Service:

List<NameOnlyDTO> projections = sampleRepository.findAllNameOnlyConstructorProjection();

Repository:

@Query("select new path.to.dto.NameOnlyDTO(e.name) from SampleEntity e")
List<NameOnlyDTO> findAllNameOnlyConstructorProjection();

Data transfer object:

@NoArgsConstructor
@AllArgsConstructor
public class NameOnlyDTO {
    private String name;
}

3. Interface projection

Service:

List<NameOnly> projections = sampleRepository.findAllNameOnlyBy();

Repository:

List<NameOnly> findAllNameOnlyBy();

Interface:

public interface NameOnly {
    String getName();
}

4. Tuple projection

Service:

List<Tuple> projections = sampleRepository.findAllNameOnlyTupleProjection();

Repository:

@Query("select e.name as name from SampleEntity e")
List<Tuple> findAllNameOnlyTupleProjection();

5. Dynamic projection

Service:

List<DynamicProjectionDTO> projections = sampleRepository.findAllBy(DynamicProjectionDTO.class);

Repository:

<T> List<T> findAllBy(Class<T> type);

Data transfer object:

public class DynamicProjectionDTO {

    private String name;

    public DynamicProjectionDTO(String name) {
        this.name = name;
    }
}


Some additional info:

The project was built using gradle spring boot plugin (version 2.0.4), which uses Spring 5.0.8 under the hood. Database: H2 in memory.

Results:

Entity projections took 161.61 ms on average out of 100 iterations.
Constructor projections took 24.84 ms on average out of 100 iterations.
Interface projections took 252.26 ms on average out of 100 iterations.
Tuple projections took 21.41 ms on average out of 100 iterations.
Dynamic projections took 23.62 ms on average out of 100 iterations.
-----------------------------------------------------------------------
One iteration retrieved (from DB) and projected 100 000 objects.
-----------------------------------------------------------------------

Notes:

It is understandable that retrieving entities takes some time. Hibernate tracks these objects for changes, lazy loading and so on.

Constructor projections are really fast and have no limitations on the DTO side, but require manual object creation in @Query annotation.

Interface projections turned out to be really slow. See question.

Tuple projections were the fastest, but are not the most convinient to play with. They need an alias in JPQL and the data has to be retrieved by calling .get("name") instead of .getName().

Dynamic projections look pretty cool and fast, but must have exactly one constructor. No more, no less. Otherwise Spring Data throws an exception, because it doesn't know which one to use (it takes constructor parameters to determine which data to retrieve from DB).

Question:

Why interface projections take longer than retrieving entities? Each interface projection returned is actually a proxy. Is it so expensive to create that proxy? If so, doesn't it defeat the main purpose of projections (since they are meant to be faster than entities)? Other projections look awesome tho. I would really love some insight on this. Thank you.

EDIT : Here is the test repository: https://github.com/aurora-software-ks/spring-boot-projections-test in case you want to run it yourself. It is very easy to set up. Readme contains everything you need to know.

Pantisocracy answered 17/11, 2018 at 0:29 Comment(8)
So you are worrying about 2.5ms for retrieving 100000 objects in a method call which takes probably about 300ms. Also make sure you are running a proper test (with warm-up iterations etc. etc.). And run each test individually (not 1 test with multiple testcases but a sperate test, including loading of JVM etc. etc.). But as they are proxies and are wrapped around the entity I would suspect that they are indeed slower then the entity. However all in all feels like pre-mature optimization.Klina
Hey, thanks for the comment. This test has been done after the warm-up iterations. It is not a unit test, it was conducted after fully starting up the project, warming it up by performing this call a couple of times and then calling it once again to test the projections. The results were all almost identical tho. Also it is not about 2.5 ms. One iteration (projecting 100 000 objects) takes 252 ms on average out of 100 tries. Using a real business logic with relations, multiple calls and other stuff would probably make it even slower. This test is merely to figure out which ones are better.Pantisocracy
Any chance of making those tests available? Maybe even as a pull request?Stopper
@JensSchauder Sure. I will do it in a few hours because I am not at home right now. I will create a public repo and let you know about it in the next comment. Thanks for taking interest in this.Pantisocracy
No hurry, it will take some time until I'll be able to look into this.Stopper
@JensSchauder I've added the repository link in the original post at the very bottom. By "some time" do you mean hours or days? I'm asking because I'm very curious what is going on here, but take your time :) Thanks.Pantisocracy
@JensSchauder Alright. Just please let us know once you have some info.Pantisocracy
It's been 2 weeks now, so I started a bounty. Really curious about this one.Pantisocracy
P
19

I experienced similar behavior with an older version of Spring Data and this was my take on it: https://arnoldgalovics.com/how-much-projections-can-help/

I had a talk with Oliver Gierke (Spring Data lead) and he made some improvements (that's why you get so "good" results :-) ) but basically there will be always a cost on having abstractions vs coding it manually.

This is a trade-off as everything else is. On one hand you got flexibility, easier development, less maintenance (hopefully), on the other hand you get full control, a bit uglier query model.

Plain answered 1/12, 2018 at 12:1 Comment(2)
Hey, thanks for answering. I've read your article and yeah, it looks like the same "issue". Anyway, I'd rather prefer full control or just use dynamic projections with 1 constructor than having such times. So this behaviour is more or less intended right? If so, I believe there should be a mention in the documentation that these kind of projections are the slowest and even slower than retrieving entities, because people mainly use it to improve performance.Pantisocracy
I mean yeah, using more level of abstraction don't come without cost so it is completely expected. Personally I wouldn't put it into the docs for one reason, the main purpose of using Spring Data is to get started quickly and cover general use-cases. As soon as you want to have the best possible performance, you have to get rid of the abstractions anyway.Plain
L
1

Each one has its Pros and Cons:

Interface projection : Nested, dynamic and open projection allowed, but Spring generates proxy at runtime.

DTO projection : Faster, but nested, dynamic and open projection not allowed.

Libertylibia answered 13/4, 2022 at 21:20 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.