Improve mapping performance caused by overuse of Optional and Stream [DATACMNS-1101]

[spring-projects-issues]

Mark Paluch opened DATACMNS-1101 and commented

Since Kay 2.0 M2 we experience a heavy negative performance impact during mapping-based object conversion. This is caused by heavy usage of Optional and Stream APIs without caching of the resulting values. PropertyValueProvider requires Optional wrapping for each get and set operation. Following the Optional programming model creates a huge amount of instances which reflect in direct increased CPU usage and CPU usage (timing jitter) because of a high GC pressure.

Java 8 Stream API usage in hot code paths allocates object instances during streaming. Non-cached results cause Stream object allocation which also reflect in decreased performance.

We should remove Optional from the main paths and keep it only if cached and use it along optional.orElse(null). Optional is well-suited for presence and absence caching. We also should introduce caches in front of Stream usage to retain improved code readability but not pay the cost of Stream instances on each invocation

---

Affects: 2.0 M4 (Kay)

Issue Links:

• DATAJPA-1143 Adapt to API changes in mapping subsystem
  ("is depended on by")

• DATAMONGO-1730 Adapt to API changes in mapping subsystem
  ("is depended on by")

• DATAREST-1104 Adapt to API changes in mapping subsystem
  ("is depended on by")

• DATACASS-473 Adapt to API changes in mapping subsystem

• DATAES-369 Adapt to API changes in mapping subsystem

• DATAGEODE-17 Adapt to API changes in mapping subsystem

• DATAGRAPH-1009 Adapt to API changes in mapping subsystem

• DATAKV-184 Adapt to API changes in mapping subsystem

• DATAREDIS-660 Adapt to API changes in mapping subsystem

• DATASOLR-406 Adapt to API changes in mapping subsystem

• SGF-640 Adapt to API changes in mapping subsystem