## 5 Experimental Evaluation and Results
### Comparative Performance  
In order to assess the fundamental performance of our design, we conducted measurements on single-threaded operations using different data sizes. We specifically focused on data insertion operations, as they provide insights into the underlying performance limitations. By comparing the performance of these operations, we were able to evaluate the efficiency of our scheme. The results, depicted in Figure 5, clearly demonstrate that ESH outperformed both the CCEH and Dash hashing schemes. In fact, our scheme exhibited a 30% improvement compared to CCEH and a 4% improvement compared to Dash when inserting large datasets. These findings highlight the superior performance of our scheme in handling larger volumes of data. As depicted in Figure 5, ESH consistently outperformed the other schemes in terms of performance. This can be attributed to the effective utilization of time that would otherwise be spent on the expensive operation of directory doubling. By delaying and optimizing the directory doubling process, ESH is able to allocate that time to insert records into the already created hashing table. This approach significantly enhances the overall performance of the scheme, resulting in improved efficiency compared to the other schemes. For a large amount of data, the overhead of full-table rehashing is significantly higher, but in this mechanism we managed to delay and add more records to the already created buckets. This  
Figure 5: Single-thread data insertion performance comparison under a fixed key length. is because rehashing is faster as the number of buckets is small, and it is not advantageous to store records in other buckets than the designated buckets in the event of overflow. The experiment in Figure 5 alone is not detailed enough to show how ESH outperforms the schemes. On top of this experiment, it was critical to show the number of probes in the event of an overflow, since probing is used to traverse the other buckets before we find a free slot to insert the key and then save the address in the OFRB. The number of buckets and segment sizes should be equal for all approaches for a fair analysis, therefore, there should be an equal number of overflows during key insertions. So it is more interesting to see the total number of probes of ESH as compared to Dash and CCEH. The insert time alone does not show the inner details of why ESH outperforms the other solutions. When examining the performance of Dash and ESH with increasing sizes of key-value stores, both schemes demonstrated comparable levels of performance. However, they both outperformed CCEH, with ESH achieving up to three times better performance. This can be attributed to the utilization of metadata in Dash and the use of fingerprints in ESH, which contribute to more efficient operations and improved performance compared to the CCEH scheme. While CCEH initially exhibited better performance with small data sizes, its performance gradually decreased as the data size increased. This can be attributed to its use of cache-line-sized data, which allows for faster flushing and completion of hashing operations within a shorter timeframe compared to other hashing schemes. However, as the data size grows, the limitations of this approach become more apparent, resulting in reduced performance compared to alternative schemes. Our scheme treats the insertion of a record to allocated positions, as well as cases of overflows. We will show the hash table operation as follows. When an insert operation is requested for a record, if there is no space available in the original bucket, but there is space available in a neighboring bucket, ESH stores the record in the neighboring bucket to delay the rehashing. This insert operation is illustrated in Figure 6, as well as how it is handled in ESH as a result.