-
Notifications
You must be signed in to change notification settings - Fork 682
Using Interface-Based Projections Requires a Lot of Heap Memory #2831
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for bringing this to our attention. Projections are associated with an invocation handler and a backing object at least which requires much more memory than a plain We will have a look into our infrastructure and whether we can optimize our projection support. |
We have indeed quite an increased memory usage profile due to the recreation of I tweaked your example to 400.000 proxy objects resulting in about 1500MB of memory usage. After caching the Spring Framework internally applies several recomputations therefore bulk creation can quickly get costly due to the allocation of various objects. Let me see whether there's additional potential for optimization (roughly another 20-30MB) |
Thank you for looking into this!
That's a good improvement! Still, using almost 1 KB to represent something as small as a Long is rather wasteful but much better than using 4 KB 🎉 |
We now reduce allocations of DefaultMethodInvokingMethodInterceptor by reusing DefaultMethodInvokingMethodInterceptor within a ProxyProjectionFactory. We also reduced allocations during default method discovery and reuse the default methods information within the projection information cache. Closes #2831
We now reduce allocations of DefaultMethodInvokingMethodInterceptor by reusing DefaultMethodInvokingMethodInterceptor within a ProxyProjectionFactory. We also reduced allocations during default method discovery and reuse the default methods information within the projection information cache. Closes #2831
We now reduce allocations of DefaultMethodInvokingMethodInterceptor by reusing DefaultMethodInvokingMethodInterceptor within a ProxyProjectionFactory. We also reduced allocations during default method discovery and reuse the default methods information within the projection information cache. Closes #2831
When using the feature of interface-based projection the amount of memory that is required is significant. This has been causing issues in production system in our services that have not been able to serve records with more 2 GB of heap even though the actual payload was estimated in the order of magnitude of 10 MB.
I have build a minimal working example to illustrate the issue. It's using:
org.springframework.boot:spring-boot-starter-data-jpa:3.06
openjdk Temurin-18.0.2.1+1
The example saves 100k entities in a H2 in-memory database (the same pattern can be observed when using e.g. postgres). Then it reads the ids of those entities 1) using an interface-based projection or 2) just plain Longs. While it is expected that the second representation is smaller than the first one the difference seems too big to be acceptable:
Steps
The text was updated successfully, but these errors were encountered: