Performance degradation in SpEL expression evaluation [SPR-16942]

[spring-projects-issues]

Kanthi Vaidya opened SPR-16942 and commented

We are planning to move from Spring 4.3.6 to Spring 5. We noticed a considerable dip in performance. About 50% degradation.

#21421 talks about a specific hot spot. Please look at attached benchmarks in that JIRA.

 

 

Juergen, I saw your code changes for caching the SortedMethods. We don't benefit much if you don't make your ConcurrentHashMap of sorted methods  a static variable.

Even after making the ConcurrentHashMap a static variable, we still don't get back the original performance of the prior spring versions. It definitely helps of course.

This is just one hotspot. More benchmarking and profiling is needed to identify other hot spots. And it probably makes sense to add a test case to the CI infrastructure to catch any such degradations.

This performance degradation, is preventing us from migration to Spring 5.

 

---

Affects: 5.0.7

Issue Links:

• Support for SimpleEvaluationContext in SpEL [SPR-16588] #21130 Support for SimpleEvaluationContext in SpEL
• ReflectivePropertyAccessor should cache sorted methods [SPR-16882] #21421 ReflectivePropertyAccessor should cache sorted methods

0 votes, 5 watchers

[spring-projects-issues]

Christoph Dreis commented

Hi, I noticed this as well recently. The caching solution in #21421 helps only in situations were the ReflectivePropertyAccessor and/or EvaluationContext is not created over and over again. Spring Security`s WebExpressionVoter or more specifically AbstractSecurityExpressionHandler is creating a StandardEvaluationContext with a fresh ReflectivePropertyAccessor every time for example and thus not benefitting much of the cache.

I therefore wonder if we should additionally look at the call-sites and enhance them if possible - similar to what the framework does in some of the annotation relevant code in order to prevent the costly checks in AnnotationUtils or AnnotatedElementUtils.

[spring-projects-issues]

Juergen Hoeller commented

Christoph Dreis, it is definitely recommended to reuse EvaluationContext instances as far as possible, preferring the use of Expression.getValue with a root object argument over a context-bound root object if necessary. SimpleEvaluationContext (#21130) strongly suggests this usage model on a recent note. And for our internal use of StandardEvaluationContext, we follow the same guideline: see e.g. the expression context caching in StandardBeanExpressionResolver.

So please report any such obvious cases to the corresponding projects if they are not aware of it already.

[spring-projects-issues]

Christoph Dreis commented

I figured already - hence the comment. See it as an addendum to the work that might be done in the Framework itself, which I think is still necessary. But I believe the projects that make use of it are able to optimize the calls themselves as well. I'll let you know once I created the issue(s) in the respective projects.

[spring-projects-issues]

Christoph Dreis commented

spring-projects/spring-security#5622

[hradilf]

Hi @spring-issuemaster,
please, is there any estimation when this issue will be solved?
Thank you.

[hradilf]

@spring-issuemaster Any update please? Thanks.

[snicoll]

With #31617 being implemented now, we no longer see this issue as actionable. Please give Spring Framework 6.1.x a try. If you're still experiencing performance issue, a new issue with additional details is more than welcome. Thanks!