4 ms·

A mandatory comment that reducing random memory fetches is often way more important to perf than O() cost. Random memory read costs a lot. https://blog.cloudfl

• pickledish 4y ago
  This was an excellent post, learned a lot, thanks for linking it!
• gsaussy 4y ago
  True. I suspect improved filter performance is most useful for database development where preventing a read from unnecessarily hitting disk is the name of the game.
• vlmutolo 4y ago
  This is one of the things Cuckoo filters do well: they need either one or two memory accesses per query, compared to a Bloom filter which needs k accesses (where k is typically greater than 5).
• hinkley 4y ago
  We have a big collective blindspot about the implications of order of complexity when you get down to O(nlogn), and to a lesser extent anything in the neighborhood of O(n√n), which is rarer but does happen. A logn slowdown versus a linear speedup of two orders of magnitude - or more - is a set of lines that don't cross for any value of n any of us will see in our lifetimes, even if you're highly placed at a FAANG. The entire output of data from CERN throughout its entire history is a rounding error compared to n = 2^100. And the fact of the matter is that long before n = 2^100, all of those constant time calculations we count on in Knuth's model of orders of complexity go from O(1) time to O(logn) anyway, so there is no such thing as an O(1) or O(n) algorithm when you have to represent everything as bignums.