[
https://issues.apache.org/jira/browse/GEODE-9256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346256#comment-17346256
]
ASF subversion and git services commented on GEODE-9256:
--------------------------------------------------------
Commit a74e4bf084c5be52efa0e072dc588472e0231f83 in geode's branch
refs/heads/develop from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a74e4bf ]
GEODE-9256: Adding a jmh test of the Object2ObjectOpenCustomHashmapWithCursor
(#6482)
The test compares the performance of the cursor with the performance
of an iterator. Although the cursor is about an order of magnitude
slower than an iterator, the iteration time still looks like it's
O(1) - eg the time to iterate per entry does not go up with the
number of entries.
Tweaking the name of the elementAtHashesTo method, based on feedback
from the last PR. Trying to make that code a little more readable.
> Remove hscan related fields from redis hash
> -------------------------------------------
>
> Key: GEODE-9256
> URL: https://issues.apache.org/jira/browse/GEODE-9256
> Project: Geode
> Issue Type: Improvement
> Components: redis
> Reporter: Dan Smith
> Assignee: Dan Smith
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> To implement hscan it looks like we added a number of fields to every redis
> hash.
> {code}
> private ConcurrentHashMap<UUID, List<ByteArrayWrapper>> hScanSnapShots;
> private ConcurrentHashMap<UUID, Long> hScanSnapShotCreationTimes;
> private ScheduledExecutorService HSCANSnapshotExpirationExecutor = null;
> {code}
> This greatly increases the per hash overhead of radish. We also create
> HSCANSnapshotExpirationExecutor for every hash that has an active hscan,
> potentially using a lot of threads.
> These fields should be removed from the hash itself so we are not increasing
> its overhead. If we need to maintain state related to hscan it should
> probably be in some client specific data structure like the
> ExecutionHandlerContext.
> Redis itself looks like it doesn't maintain any server side state. We should
> use the same stateless cursor algorithm as redis and avoid keeping any state
> on the server. Here's an article that goes in depth on the redis algorithm
> https://www.freecodecamp.org/news/redis-hash-table-scan-explained-537cc8bb9f52/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
