Cache detected factory methods in ObjectToObjectConverter [SPR-13703]

[spring-projects-issues]

Oliver Drotbohm opened SPR-13703 and commented

ObjectToObjectConverter currently rediscovers the methods to use on every conversion which can cause quite some performance implication if it's used heavily.

We've got DATAMONGO-1324 filed observing that behavior. Although the performance decrease is caused by a more explicit converter accidentally not being registered out of the box, I wonder whether caching the detected methods could improve performance for the scenarios ObjectToObjectConverter is used on purpose.

---

Affects: 4.2.3

Referenced from: commits 3234d9e, 44651fd

[spring-projects-issues]

Juergen Hoeller commented

We're caching the most recently used to-method, factory-method and factory-constructor for each class now, if any.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Oliver Drotbohm, any chance you could re-run the tests that triggered this issue originally? Even if you have an explicit converter for that scenario now, you could temporarily unregister it and see where you'll end up performance-wise against ObjectToObjectConverter in its current form... That said, I still recommend registering an explicit converter wherever possible.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Reopened for upfront cache checks, avoiding unnecessary searches for other kinds of methods if a specific match is known for the given convertible pair already.

[spring-projects-issues]

Juergen Hoeller commented

I've just committed another revision, now using a centralized cache and skipping further reflective resolution attempts if a cache entry is present already. Please give it a try, Oliver Drotbohm...

In the course of this, I've also added an explicit condition for a no-parameter toXXX method to be declared as non-static. It doesn't make sense otherwise, and it makes our cache entry handling easier since non-static versus static reliably identifies a toXXX method versus a factory method then. I've also streamlined the condition checks between matches / convert and FallbackObjectToStringConverter for consistent handling of String targets.

Juergen

[spring-projects-issues]

Oliver Drotbohm commented

Changes look good to me. Running the sample project provided in the related ticket gives the following numbers:

• Before optimizations: ObjectToObjectConverter 359ms, dedicated converter 30ms.
• After optimizations: ObjectToObjectConverter 32ms, dedicated converter 30ms.