Skip to content
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

Speed up dynamic instantiation of objects with compiled SpEL expressions [SPR-12330] #16935

Closed
spring-projects-issues opened this issue Oct 14, 2014 · 3 comments
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Oct 14, 2014

Thomas Darimont opened SPR-12330 and commented

In a lot of places within the Spring framework, objects are dynamically instantiated via reflection.
This way of creating object instances can be quite slow (since the JVM doesn't speed this up, yet).
With the advent of compiled SpEL expressions we have a way to create instances much faster.
Once #16931 is fixed we could just create SpEL Expression's that contains appropriate constructor
invocations, parse and compile them at bootstrap time and store them in a shared map read-only map.

Once a new instance of a type T is requested, we could simply lookup the compiled SpEL Expression
with the appropriate constructor invocation for T and just call it's getValue(...) method to obtain the actual instances.

We currently do something similar in Spring Data Commons: (spring-projects/spring-data-commons#98)
In our case we generate ASM code by hand since we cannot rely on Spring 4.1+ being available.

Of course not all reflective object instantiations can be replaced with this approach (e.g. classes with non-public ctors), but since the relevant types are often public(*1) and have public ctors it should be possible in the majority of cases.

The dynamic expression compilation/generation could introduce a performance penalty (at startup) which should payoff (IMHO) quite quickly in the long run.

(*1) if one could adjust the package name of the classes generated for compiled SpEL expression one could even instantiate package scoped classes with public ctors.


Affects: 4.1.1

0 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

I wonder whether this makes a significant difference for the typical instances that the Spring application context instantiates. Since we're usually injecting a bunch of fields and/or methods via reflection afterwards, the gain from non-reflective instantiation may not really show for those kinds of objects. Even without field/method injection, all the handling that the container applies around the actual bean instantiation itself might be more significant than instantiation efficiency.

That said, for highly demanded request-scoped beans with constructor injection only, it might nevertheless deliver a significant enough benefit. We should at least evaluate that option.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Thomas Darimont commented

Thanks for the quick response :)

I think this would also apply to injected CDI Provider's (our our ObjectFactory) especially in combination with prototype beans.

@spring-projects-issues spring-projects-issues added status: waiting-for-triage An issue we've not yet triaged or decided on type: enhancement A general enhancement in: core Issues in core modules (aop, beans, core, context, expression) and removed type: enhancement A general enhancement labels Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process
Projects
None yet
Development

No branches or pull requests

2 participants