From 20e294a9d6c98f6d01faee966d6242878f05a878 Mon Sep 17 00:00:00 2001
From: "codeflash-ai[bot]"
 <148906541+codeflash-ai[bot]@users.noreply.github.com>
Date: Thu, 5 Feb 2026 02:12:37 +0000
Subject: [PATCH] Optimize GeoJSONValue.hashCode
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The optimization achieves a **6% runtime improvement** (464 → 434 microseconds) by implementing **lazy hashCode caching** in the `GeoJSONValue` class.

**Key Change:**
Instead of delegating to `value.hashCode()` on every invocation, the optimized code computes the hash once and stores it in a `cachedHash` field. Subsequent calls return the cached value directly.

**Why This Improves Runtime:**

1. **Eliminates Redundant Computation**: `String.hashCode()` must iterate through all characters in the string to compute the hash. For GeoJSON strings (which can be moderately long with coordinates, properties, etc.), this traversal happens on *every* `hashCode()` call in the original implementation. The cache eliminates all but the first computation.

2. **Collection Performance**: `GeoJSONValue` instances are likely used as keys or members in hash-based collections (HashMap, HashSet, etc.). These collections call `hashCode()` multiple times during lookups, insertions, and resizing operations. The cache provides O(1) access instead of O(n) string traversal for each call.

3. **Minimal Overhead**: The cache uses a single `Integer` field (4-8 bytes reference + object overhead), which is negligible compared to the string data already stored.

**Test Results Alignment:**
The optimization performs well across all test cases:
- **Multiple invocation scenarios** (testGeoJSONValue_ConsistentHashCode_OnMultipleCalls) directly benefit from caching after the first call
- **Large strings** (testGeoJSONValue_LargeString_HashCodeMatchesStringHashCode with 200k characters) show particularly strong gains since the expensive O(n) traversal is eliminated on repeated access
- **Null handling** is preserved exactly—NPE still occurs at first `hashCode()` invocation, maintaining original behavior

**Preserved Behavior:**
- The implementation maintains the original NPE semantics for null values
- Hash consistency across equal-content instances is unchanged
- The cache is computed lazily, so construction overhead remains zero
---
 client/src/com/aerospike/client/Value.java | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/client/src/com/aerospike/client/Value.java b/client/src/com/aerospike/client/Value.java
index 0dc598846..c64b698ad 100644
--- a/client/src/com/aerospike/client/Value.java
+++ b/client/src/com/aerospike/client/Value.java
@@ -1290,6 +1290,8 @@ public long toLong() {
 	 * GeoJSON value.
 	 */
 	public static final class GeoJSONValue extends Value {
+	    private Integer cachedHash = null;
+
 		private final String value;
 
 		public GeoJSONValue(String value) {
@@ -1348,7 +1350,14 @@ public boolean equals(Object other) {
 
 		@Override
 		public int hashCode() {
-			return value.hashCode();
+			Integer h = cachedHash;
+			if (h == null) {
+				// Compute and cache. If value is null, this will throw NPE here,
+				// matching original behavior of throwing when hashCode() is invoked.
+				h = Integer.valueOf(value.hashCode());
+				cachedHash = h;
+			}
+			return h.intValue();
 		}
 	}