You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not so much a feature request as a performance improvement request (which I'm happy to submit a PR for).
We're using Lettuce (cluster) at Faire, and recently encountered a performance issue when making MGETs with a large number (10k+) of long strings (30 characters or more), with a large shared prefix.
The issue is that indexOf has very poor performance for this scenario, as checking string equality is expensive. My proposal is that we create a Map<String, Int> upfront for each value in partitioned, which will be O(n). Then we use that instead of indexOf, and do the position lookups in constant time. This should improve performance at the cost of higher memory usage, but it will get GC'd immediately after so it feels like a worthwhile tradeoff.
Happy to discuss further!
The text was updated successfully, but these errors were encountered:
Not so much a feature request as a performance improvement request (which I'm happy to submit a PR for).
We're using Lettuce (cluster) at Faire, and recently encountered a performance issue when making MGETs with a large number (10k+) of long strings (30 characters or more), with a large shared prefix.
We noticed that we had extremely high CPU usage after the MGETs completed, while still inside the Lettuce code. We eventually traced it to this line: https://github.com/lettuce-io/lettuce-core/blob/4110f2820766c4967951639aa2b6bdd9d50466be/src/main/java/io/lettuce/core/cluster/RedisAdvancedClusterAsyncCommandsImpl.java#L307
The issue is that
indexOf
has very poor performance for this scenario, as checking string equality is expensive. My proposal is that we create aMap<String, Int>
upfront for each value inpartitioned
, which will beO(n)
. Then we use that instead ofindexOf
, and do the position lookups in constant time. This should improve performance at the cost of higher memory usage, but it will get GC'd immediately after so it feels like a worthwhile tradeoff.Happy to discuss further!
The text was updated successfully, but these errors were encountered: