[infinispan-issues] [JBoss JIRA] (ISPN-8517) Lazily ressurect ice fromMemory

William Burns (JIRA) issues at jboss.org
Thu Nov 9 14:42:00 EST 2017


    [ https://issues.jboss.org/browse/ISPN-8517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488405#comment-13488405 ] 

William Burns commented on ISPN-8517:
-------------------------------------

I ran some tests comparing get performance between the new and old and it is a bit faster (I also added a preinsert as gets were always misses with no entries before so we could see that perf better)

https://gist.github.com/wburns/f74db9ac854552c0babea6fb53282291

> Lazily ressurect ice fromMemory
> -------------------------------
>
>                 Key: ISPN-8517
>                 URL: https://issues.jboss.org/browse/ISPN-8517
>             Project: Infinispan
>          Issue Type: Sub-task
>          Components: Off Heap
>    Affects Versions: 9.2.0.Alpha2
>            Reporter: William Burns
>            Assignee: William Burns
>
> Currently many places do 
> {code}
> ice = ice = offHeapEntryFactory.fromMemory(address)
> if (wrappedKey.equalsWrappedBytes(ice.getKey()))
> {code}
> In cases where this ends up being a miss, we read the entire value which is wasteful. And the CPU may not have the key in the cache size we read the object into memory. Where as if we do 
> {code}
> if (offHeapEntryFactory.equalsKey(address, key))
> ice = ice = offHeapEntryFactory.fromMemory(address)
> {code}
> we know that CPU is reading from the address location twice in a row, which has a very high chance of still being in CPU caches which should hopefully provide better performance. We also then don't have to read the entire ice object in memory unless there was a hit.
> We also should change _performGet_ to return the address instead of the ice. This way callers can use this address for other optimizations such as when doing a _evict_ or _compute_ which have to read the entry first before a remove.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


More information about the infinispan-issues mailing list