1. 14 Nov, 2024 1 commit
  2. 13 Nov, 2024 2 commits
  3. 11 Nov, 2024 2 commits
  4. 08 Nov, 2024 4 commits
  5. 07 Nov, 2024 1 commit
  6. 06 Nov, 2024 3 commits
  7. 05 Nov, 2024 1 commit
  8. 04 Nov, 2024 2 commits
  9. 01 Nov, 2024 1 commit
  10. 30 Oct, 2024 1 commit
  11. 28 Oct, 2024 1 commit
  12. 23 Oct, 2024 5 commits
  13. 22 Oct, 2024 1 commit
    • Marks absl::Span as view and borrowed_range, like std::span. · 87831365
      This allows containers that either optimize based on these
      concepts or produce lifetime warnings based on them to
      handle absl::Span appropriately. An example is Chromium's
      base::span, which warns more aggressively about construction
      from rvalues that are not borrowed ranges.
      
      This only has an effect for codebases using C++20. While
      many such codebases will presumably also be using std::span
      directly, they may use absl::Span for backwards compat, or
      compile against libraries that do so.
      
      Also fixes lint's that fired when I tried to edit this.
      
      PiperOrigin-RevId: 688552975
      Change-Id: I603e04cd74d60ac6b65754ac73037d7f0ab457fe
      Abseil Team committed
  14. 17 Oct, 2024 1 commit
  15. 15 Oct, 2024 1 commit
  16. 14 Oct, 2024 1 commit
  17. 11 Oct, 2024 1 commit
  18. 10 Oct, 2024 2 commits
  19. 08 Oct, 2024 1 commit
  20. 02 Oct, 2024 2 commits
    • Improve ABSL_ASSERT performance by guaranteeing it is optimized away under NDEBUG in C++20 · 03b8d6ea
      Also fix the old definition by verifying that the condition is contextually convertible to bool.
      
      The new C++20 definition reduces codegen bloat and guarantees fast performance while still retaining the expression (so that unused-variable warnings don't trigger).
      
      As an example where this makes a difference, compare the following snippet under `-DABSL_INTERNAL_CPLUSPLUS_LANG=202002`: https://godbolt.org/z/hjf59n84v
      ```
      #include <stdlib.h>
      template<class T> struct S { S() { abort(); } static S const s; };
      template<class T> S<T> const S<T>::s = {};
      #if ABSL_INTERNAL_CPLUSPLUS_LANG >= 202002L
      #define ABSL_ASSERT(expr) (decltype((expr) ? void() : void())())
      #else
      #define ABSL_ASSERT(expr) (false ? ((expr) ? void() : void()) : void())
      #endif
      void foo() { ABSL_ASSERT(((void)&S<int>::s, true)); }
      ```
      
      We see that, in unoptimized builds, code is still generated with the old definition of `ABSL_ASSERT`. Moreover, even under optimizations (with `-O2`), the call to abort() still lingers with the old definition of `ABSL_ASSERT`.
      
      Therefore the extra generated code can affect both compile- and run-time performance.
      
      PiperOrigin-RevId: 681563573
      Change-Id: I7fbfadcc7fd198e8e1daf14615c33687f6b23af7
      Abseil Team committed
    • Mark Abseil hardening assert in AssertSameContainer as slow. · 5d347078
      When Abseil hardening is enabled, this assertion's condition gets evaluated every time an iterator equality check is performed on iterators from a raw_hash_set.  This occurs very frequently when looping over the contents of sets, due to loop conditions like `it != end()`, and causes about 0.4% CPU overhead to some Google workloads.
      
      PiperOrigin-RevId: 681560141
      Change-Id: Ia0177cbef7cf67f9f0b6adf2cf55d9a2ed320d2d
      Abseil Team committed
  21. 27 Sep, 2024 1 commit
  22. 26 Sep, 2024 1 commit
    • Small Mutex::Unlock optimization · 482ca0b9
      Saving one "&" operation in the Mutex::Unlock fast path. This has likely no performance impact (the two AND instructions ran in parallel anyway), but is as complex as the current solution, and enables two possible improvements in the future.
      
      1. If bits Ev, Wr, Wa, De are made into the highest bits in the kMuLow,
         then the second "&" operation can be omitted because if kMuWriter is set,
         the there are no readers, so the kMuHigh bits are zero.
      
      2. If the meanings of kMuWriter and kMuDesig are flipped, then the "^"
         operation is not needed either.
      
      PiperOrigin-RevId: 679272590
      Change-Id: Iea7a04df0118d2410b7bfdab70b30e33d4b90e43
      piotrzielinski committed
  23. 24 Sep, 2024 1 commit
    • Optimize `CEscape` and `CEscapeAndAppend` by up to 40%. · ba5fd097
      - Compute the escape character values at compile time.
      - Use `little_endian::Store32` invariably to write all escaped characters.
      - Use 3 slop bytes at the end so that we can safely call `little_endian::Store32` at the end as well.
      
      PiperOrigin-RevId: 677995014
      Change-Id: I9d710fff48d0ce0b013e64d726960364c77ea1d7
      Shahriar Rouf committed
  24. 23 Sep, 2024 1 commit
  25. 20 Sep, 2024 1 commit
  26. 19 Sep, 2024 1 commit
    • Fix benchmarks in `escaping_benchmark.cc` by properly calling… · b3454256
      Fix benchmarks in `escaping_benchmark.cc` by properly calling `benchmark::DoNotOptimize` on both inputs and outputs and by removing the unnecessary and wrong `ABSL_RAW_CHECK` condition (`check != 0`) of `BM_ByteStringFromAscii_Fail` benchmark.
      
      Relevant comment:
      ```
      // The DoNotOptimize(...) function can be used to prevent a value or
      // expression from being optimized away by the compiler. This function is
      // intended to add little to no overhead.
      // See: http://stackoverflow.com/questions/28287064
      //
      // The specific guarantees of DoNotOptimize(x) are:
      //  1) x, and any data it transitively points to, will exist (in a register or
      //     in memory) at the current point in the program.
      //  2) The optimizer will assume that DoNotOptimize(x) could mutate x or
      //     anything it transitively points to (although it actually doesn't).
      //
      // To see this in action:
      //
      //   void BM_multiply(benchmark::State& state) {
      //     int a = 2;
      //     int b = 4;
      //     for (auto s : state) {
      //       testing::DoNotOptimize(a);
      //       testing::DoNotOptimize(b);
      //       int c = a * b;
      //       testing::DoNotOptimize(c);
      //     }
      //   }
      //   BENCHMARK(BM_multiply);
      //
      // Guarantee (2) applied to 'a' and 'b' prevents the compiler lifting the
      // multiplication outside of the loop. Guarantee (1) applied to 'c' prevents the
      // compiler from optimizing away 'c' as dead code.
      ```
      To see #1 and #2 in action, see: https://godbolt.org/z/ned1578ve
      
      PiperOrigin-RevId: 676588185
      Change-Id: I7ed3e4bed8274b54ac7877316f2d82c33d68f00f
      Shahriar Rouf committed