## 5 Experimental Evaluation and Results
### Comparative Performance
As a result, when a thread attempts to insert a record into bucket (\(\leavevmode\hbox to17.49 pt{\vbox to17.49 pt{\pgfpicture\makeatletter\hbox to 0.0 pt{\pgfsys@beginscope{} \definecolor{pgfstrokecolor}{rgb}{0,0,0}\pgfsys@color@rgb@stroke{0}{0}{0}{ \pgfsys@color@rgb@fill{0}{0}{0}{\pgfsys@setlinewidth{0.4 pt}{0.4 pt}{0.4 pt} \pgfsys@setlinewidth{0.4 pt}{0.4 pt}{0  
Consequently, the thread proceeds to search for the key in the neighboring bucket (bucket 1) within segment (2). However, even in bucket 1, the key is not found. Hence, the thread continues its search in the next neighboring bucket (bucket 2), as denoted by (3). Eventually, the key is found in bucket 2, allowing the thread to retrieve the corresponding value from it. In the case of a delete operation, the thread follows a similar process as the search operation described above. If the thread successfully locates the key, it proceeds to delete the corresponding record (4). This deletion operation involves reducing the overflow count of bucket 0 by 1 and decreasing the member count of bucket 2 by 1. Additionally, if bucket 2 is not already full, the overflow bit of bucket 2 is updated to 0. From the aforementioned explanation, we can conclude that the figure clearly demonstrates the sequence of search and delete operations in the given system. As records are continuously received from the client, our approach allows for their insertion into the buckets as long as there is available space in the segment. In fact, our strategy ensures that at least one record is stored in the neighboring bucket before invoking the segment split or  
Figure 6: Record insertion operation in ESH. Figure 7: Record search or deletion operation in ESH. directory doubling operation. This unique advantage becomes even more pronounced as the amount of data continues to grow. Consequently, the delay in the split and directory doubling operations becomes more significant, further enhancing the overall efficiency of our mechanism. From the experimental results, our scheme has shown that there is a delay in directory doubling as there are records stored in neighboring buckets after the initial bucket fills up. During the experiment, the delay became noticeable after the segment splitting and directory doubling happened in the first seven rounds, where more records are inserted before a directory doubling occurs. Unlike other schemes, where it is a must for the scheme to trigger a full-table rehashing operation even if neighboring buckets are empty, ESH employs an effective approach where it delays this expensive operation until all empty spaces are exhausted. In ESH, when a bucket becomes full, we utilize the neighboring buckets within the same segment by moving records into them. This strategy delays the need for a full-table rehashing operation, ensuring efficient utilization of the hash table. As a result, ESH optimizes performance by avoiding unnecessary rehashing when the hash table is actually only partially filled. By increasing the size of the buckets in our design, we were able to accommodate a larger number of records in the hash table that matches the access block size of the persistent memory. This approach leveraged the benefit of the persistent memory write block, allowing us to store more records within each bucket. As a result, we achieved improved insertion capacity and reduced the frequency of full-table rehashing. Additionally, this optimization helped to minimize unnecessary directory doubling, which can be a costly operation impacting the overall performance of the hashing scheme. To ensure successful insertion, the hashing function accesses the segments by utilizing the directory entry that provides pointers to the corresponding segments. In this design, each segment is composed of four buckets, which can be accessed through the segment's entry pointer. During the insertion operation, the segment is checked to determine if any of its buckets have sufficient space to accommodate the newly inserted value.