1. 11 Jul, 2024 3 commits
  2. 10 Jul, 2024 3 commits
  3. 09 Jul, 2024 1 commit
  4. 07 Jul, 2024 1 commit
  5. 04 Jul, 2024 1 commit
  6. 03 Jul, 2024 2 commits
  7. 02 Jul, 2024 2 commits
  8. 01 Jul, 2024 6 commits
  9. 27 Jun, 2024 5 commits
  10. 26 Jun, 2024 4 commits
  11. 25 Jun, 2024 1 commit
  12. 24 Jun, 2024 5 commits
  13. 22 Jun, 2024 2 commits
  14. 21 Jun, 2024 2 commits
  15. 20 Jun, 2024 2 commits
    • Create `absl::container_internal::c_for_each_fast` for SwissTable. · 10ac811f
      This function is aimed to achieve faster iteration through the entire hash table.
      It is not ready to be used by the public and stays in `container_internal` namespace.
      
      Differences with `absl::c_for_each`:
      1. No guarantees on order of iteration. Although for the hash table it is partially not guaranteed already. But we do not even guarantee that it is the same order as in the for loop range. De facto, the order is the same at the moment.
      2. No mutating reentrance is allowed. Most notably erasing from the hash_table is not allowed.
      
      Based on microbenchmarks, there are following conclusions:
      1. c_for_each_fast is clearly faster on big tables with 20-60% speedup.
      2. Microbenchmarks show regression on a full small table without any empty slots.
         We should avoid recommending that for small tables.
      3. It seems reasonable to use `c_for_each_fast` in places, where `skip_empty_or_deleted` has significant GCU usage. `skip_empty_or_deleted` usage signals that there are "gaps" between elements, so `c_for_each_fast` should be an improvement.
      
      PiperOrigin-RevId: 645142512
      Change-Id: I279886b8c8b2545504c2bf7e037d27b2545e044d
      Vitaly Goldshteyn committed
    • Disable flaky test cases in kernel_timeout_internal_test. · 93763764
      PiperOrigin-RevId: 645054874
      Change-Id: Ic4a820b47edfa71bd3e1f149d54f00ac3c1d16a6
      Evan Brown committed