## 5 Experimental Evaluation and Results
### Comparative Performance
If a bucket within the segment is full, the scheme initiates a bucket-splitting process and inserts the new value into the appropriate location within the split buckets. This process continues until all the buckets in the segment are filled. If the target bucket is already full but there are other buckets within the same segment that still have available space, the metadata of each neighboring bucket is examined. In this case, the new value is moved to one of these buckets, and the original bucket's OB and OFRB pointer are modified for future access. By utilizing the available space in the buckets within the segment, this approach effectively fills up the segment before triggering the directory doubling process, making efficient use of all the bucket spaces. Our scheme efficiently inserts records into all the buckets within the same segment, making optimal use of the hash table before initiating the costly full-table rehashing process. To accomplish this, we examine the header information of each bucket to determine the available free space and store the new record in the buckets with fewer key-value stores already present. The process of directory doubling involves the rehashing and redistribution of all records to buckets. During a search operation, it starts from the target bucket. If the search key does not match the header information, there is no need to loop through the elements in the bucket. Instead, it moves on to the next neighboring bucket. This transition to the next bucket is only initiated if the \"OB\" flag indicates that the bucket contains overflowed elements that have been moved to the neighboring bucket. Otherwise, the search concludes within the segment, and the result indicates that no element was found. However, if there is an overflow indicator \(OC\) for a particular bucket, the search operation will proceed to the neighboring bucket and examine the header or metadata of each bucket to see if the search key matches any elements that have been moved from another bucket. These moved elements are identified by the _membership count_ in the metadata. If the item is not found in the initially hashed bucket and the neighboring buckets within the same segment, the search for the record will be unsuccessful. As depicted in Figure 8, the search performance of ESH outperforms CCEH by a factor of two and demonstrates a 10% improvement compared to Dash. This achievement can be attributed to the utilization of metadata information, which facilitates the search operation in examining all buckets within the same segment for the desired element. Starting from a specific bucket, the search checks the bucket's header to determine if the value exists. If the value is not found in the bucket and there is no overflow indicator \(OFRB\), the search concludes within the same bucket. However, if an overflow \(OFRB\) indicator is present, the search continues from the address pointed to by the \(OFRB\) within the same segment. The experimental results clearly demonstrate the effectiveness of this mechanism and the utilization of bucket-level headers. Furthermore, in terms of delete operations, ESH exhibited superior performance compared to both schemes. The experimental results indicate that ESH outperformed CCEH and Dash by 10% and 3.2%, respectively. This performance gain in delete operations can be attributed to the fact that it builds upon the search operation, thus contributing to an overall improvement in performance.