java-driver icon indicating copy to clipboard operation
java-driver copied to clipboard

JAVA-3073 Memoize ByteOrderedToken hashCode to avoid expensive computation

Open schlosna opened this issue 2 years ago • 3 comments

While profiling a service using java-driver 3.x, in JFR output I noticed significant CPU cycles and memory allocations corresponding to computing TokenRange::hashCode(). Note that this is likely due to use of byte ordered partitioner for this Cassandra instance as the ByteOrderToken must traverse the ByteBuffer each time, and TokenRangeBase (in 4.x, TokenRange in 3.x) is using Objects.hash(start, end) that allocates an array for var args for each invocation.

image

image

image

schlosna avatar Jun 12 '23 19:06 schlosna

Filed https://datastax-oss.atlassian.net/browse/JAVA-3073

schlosna avatar Jun 26 '23 17:06 schlosna

Thanks for the PR @schlosna , and for filing the JIRA ticket! Apologies for not digging into this yet; I've been completely swamped with other work but both the analysis and the PR look very thorough so I'm hoping to dig into it soon!

Have you signed the Contributor License Agreement for contributions to DataStax open source projects? If not you can find it at https://cla.datastax.com/. Thanks!

absurdfarce avatar Jun 30 '23 15:06 absurdfarce

Thanks for taking a look @absurdfarce ! I will review and get back on the CLA.

One area where this issue pops up is when performing bulk DDL schema operations as the client is trying to stay in sync with C*. A workaround may be using the debouncing and schema disable/enable to avoid threshing the client's view of C* schemas.

  • https://docs.datastax.com/en/developer/java-driver/4.14/manual/core/performance/#debouncing
  • https://docs.datastax.com/en/developer/java-driver/4.14/manual/core/metadata/schema/#enabling-disabling

schlosna avatar Jun 30 '23 17:06 schlosna