The timing part of the current find has some issues to discuss. The time measured now includes the time used for inserts. The hash table is slowly expanded to its final size during the measurement. This brings two problems:
- The time we measured is not the time for
find function. It's the time for find and insert. And when the number of elements in the hash table is larger, the ratio of the number of insert operations to the number of find operations is larger. So this problem is especially noticeable when the number of elements is large (e.g. RandomFind_500000).
- The time of
RandomFind_N is not the time measured on a hash table of size N. It's the average time for all hash tables of size 1 to size N. This makes the results less informative for users who want to know the performance of a hash table of size N.
In summary, I think the method of measuring time in the find section should be improved.
The timing part of the current
findhas some issues to discuss. The time measured now includes the time used for inserts. The hash table is slowly expanded to its final size during the measurement. This brings two problems:findfunction. It's the time forfindandinsert. And when the number of elements in the hash table is larger, the ratio of the number of insert operations to the number of find operations is larger. So this problem is especially noticeable when the number of elements is large (e.g.RandomFind_500000).RandomFind_Nis not the time measured on a hash table of size N. It's the average time for all hash tables of size 1 to size N. This makes the results less informative for users who want to know the performance of a hash table of size N.In summary, I think the method of measuring time in the find section should be improved.