• Type: Enhancement
• Resolution: Obsolete
• Priority: Major
• Fix Version/s: None
• Affects Version/s: None
• Component/s: Core
• Labels:

  • performance

[ISPN-6484] MarshallableTypeHints.getBufferSizePredictor(Class) is very hot

Collapse comment: Tristan Tarrant added a comment - 2024/11/27 2:57 PM

Tristan Tarrant added a comment - 2024/11/27 2:57 PM

Infinispan issue tracking has been migrated to GitHub issues: https://github.com/infinispan/infinispan/issues
If you still want this issue to be worked on, create a new issue on GitHub and link this issue.

Expand comment: Tristan Tarrant added a comment - 2024/11/27 2:57 PM

Tristan Tarrant added a comment - 2024/11/27 2:57 PM Infinispan issue tracking has been migrated to GitHub issues: https://github.com/infinispan/infinispan/issues If you still want this issue to be worked on, create a new issue on GitHub and link this issue.

Collapse comment: Sanne Grinovero (Inactive) added a comment - 2016/06/20 5:20 AM, Edited by Sanne Grinovero - 2016/06/20 5:20 AM

Sanne Grinovero (Inactive) added a comment - 2016/06/20 5:20 AM - edited

Note: in the description I suggested the option of using a special purpose data structure.

The reason is that I created a Map-like implementation for Hibernate ORM which is optimised for very fast lookups. It's definitely not a general-purpose Map implementation but it might fit this use case well too.
Generally:

• it needs to use Class as a key
• it's extremely non-efficient at writes (only a good choice if it's very hot at reads but writes are part of the "setup")
• it's meant for small collections, i.e. design was intended for less than 32 elements.. could work fine with some ~512 I guess but that's not tested..

See org.hibernate.service.internal.ConcurrentServiceBinding.

I'd also experiment the effects of using a "no-op" predictor to see if it's all worth it.

Expand comment: Sanne Grinovero (Inactive) added a comment - 2016/06/20 5:20 AM, Edited by Sanne Grinovero - 2016/06/20 5:20 AM

Sanne Grinovero (Inactive) added a comment - 2016/06/20 5:20 AM - edited Note: in the description I suggested the option of using a special purpose data structure. The reason is that I created a Map-like implementation for Hibernate ORM which is optimised for very fast lookups. It's definitely not a general-purpose Map implementation but it might fit this use case well too. Generally: it needs to use Class as a key it's extremely non-efficient at writes (only a good choice if it's very hot at reads but writes are part of the "setup") it's meant for small collections, i.e. design was intended for less than 32 elements.. could work fine with some ~512 I guess but that's not tested.. See org.hibernate.service.internal.ConcurrentServiceBinding . I'd also experiment the effects of using a "no-op" predictor to see if it's all worth it.