* then the effect of the function is non-existent: we serve storedPermits at exactly the same
   * cost as fresh ones (1/QPS is the cost for each). We use this trick later.
   *
   * If we pick a function that goes /below/ that horizontal line, it means that we reduce the area
   * of the function, thus time. Thus, the RateLimiter becomes /faster/ after a period of

      sort(
          insertionOrder,
          new Comparator<V>() {
            @Override
            public int compare(V left, V right) {
              // The indexes are small enough for the subtraction trick to be safe.
              return indexOfEntryWithValue(left) - indexOfEntryWithValue(right);
            }

            int indexOfEntryWithValue(V value) {
              for (int i = 0; i < orderedEntries.size(); i++) {

enum BloomFilterStrategies implements BloomFilter.Strategy {
  /**
   * See "Less Hashing, Same Performance: Building a Better Bloom Filter" by Adam Kirsch and Michael
   * Mitzenmacher. The paper argues that this trick doesn't significantly deteriorate the
   * performance of a Bloom filter (yet only needs two 32bit hash functions).
   */
  MURMUR128_MITZ_32() {
    @Override
    public <T extends @Nullable Object> boolean put(

      sort(
          insertionOrder,
          new Comparator<V>() {
            @Override
            public int compare(V left, V right) {
              // The indexes are small enough for the subtraction trick to be safe.
              return indexOfEntryWithValue(left) - indexOfEntryWithValue(right);
            }

            int indexOfEntryWithValue(V value) {
              for (int i = 0; i < orderedEntries.size(); i++) {

     * by Kadatch and Jenkins, 2010.
     */

    Crc32cHasher() {
      super(16);
    }

    private boolean finished = false;

    /*
     * This trick allows us to avoid having separate states for "first four ints" and "all other
     * four int chunks."  The state we want after the first four bytes is
     *
     * crc0 = ~int0
     * crc1 = int1
     * crc2 = int2