Performance issue on ResolvableType cache [SPR-12122]

[spring-projects-issues]

Sébastien Deleuze opened SPR-12122 and commented

While working on Spring Flex issue FLEX-234, I have found that the ResolvableType cache can be really slow.

When there is a lot of entries in this HashMap, getting a simple value could take a lot of time, and the bottleneck seems to come from a lot of calls to ResolvableType.equals().

ResolvableType.equals() uses this.type, getSource(), this.variableResolver.getSource() and this.componentType but ResolvableType.hashCode() uses only this.type. This seems to be the root cause of these huge amount of slow equals() calls when ResolvableType.forType() try to get a value from the HashMap.

By using the same fields in ResolvableType.hashCode() than in ResolvableType.equals(), we should be able to improve performances.

I have created a benchmark project that reproduce this issue.

---

Affects: 4.0.6, 4.1 RC2

Reference URL: https://github.com/sdeleuze/spring-resolvabletype-benchmark

Issue Links:

• FLEX-234 Poor performance stemming from ObjectUtils.nullSafeEquals() calls ("is depended on by")
• memory leak in class org.springframework.core.ResolvableType [SPR-11394] #16021 memory leak in class org.springframework.core.ResolvableType

Backported to: 4.0.7

[spring-projects-issues]

Sébastien Deleuze commented

Pull request #635 submitted.

With real applications, where ResolvableCache contains thousands of entries, this improvement could allow great performances improvements. For example on the spring-resolvabletype-benchmark project:

• 8000 us before this commit
• 120 us with this commit