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

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

Closed
spring-projects-issues opened this issue Jun 26, 2017 · 0 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Jun 26, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.