Changes between Version 1 and Version 2 of Ticket #15367, comment 28


Ignore:
Timestamp:
11/12/13 23:10:43 (8 years ago)
Author:
nbruin
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #15367, comment 28

    v1 v2  
    2626where j is the number of iterations needed by lookup I think I should get something that averages 0 (since I'm subtracting the expected number of samples needed to obtain a NULL), but I'm getting way larger numbers. That indicates to me poorly randomized probing sequences.
    2727
     28Deletion is indeed also slower (as expected)
    2829
    29 Deletion is indeed also slower (as expected)
     30
     31'''EDIT:''' I think the hash indeed is very bad. If instead we do
     32{{{
     33        cdef size_t key = <size_t>key1 + 13*(<size_t>key2) ^ 503*(<size_t>key3)
     34        cdef size_t i = key>>8 + key
     35        cursor = &(table[i & mask])
     36        perturb = (key)>>3
     37}}}
     38(i.e., borrow the function originally used) I still see `summed_expected` slowly drift upward, but nowhere as quickly. I didn't do the statistics carefully, so that may even be expected. My preliminary timings show that on your test script, the new implementation now solidly outperforms the old implementation. Perhaps you want to check as well>