Abseil Blog

Perf Tips

02 Mar 2023

Performance Tips of the Week

By Alexey Alexandrov, Google Engineer

We are pleased to announce that we’ve started publishing some of Google’s internal “Performance Tips of the Week” externally on abseil.io!

These tips form a sort of “Effective analysis and optimization of production performance and resource usage”: a gallery of “do”s and “don’t”s gathered from the hard-learned lessons of optimizing performance of production systems running on machines in Google data centers.

Read more

---

Abseil Stringify

15 Nov 2022

By Phoebe Liang, Abseil Engineer

We are pleased to introduce an easier way to format user-defined types as strings in Abseil: AbslStringify(). This API allows user-defined types to be printed more easily using absl::StrFormat() and absl::StrCat().

To “stringify” a custom type, define a friend function template named AbslStringify():

struct Point 
  template <typename Sink>
  friend void AbslStringify(Sink& sink, const Point& p) {
    absl::Format(&sink, "(%d, %d)", p.x, p.y);
  }

  int x;
  int y;
}

absl::StrCat() will work right out of the box like so:

absl::StrCat("The point is ", p);

To print custom types with absl::StrFormat(), use the new type specifier %v:

absl::StrFormat("The point is %v", p);

%v uses type deduction to print an argument and supports any user-defined type that provides an AbslStringify() definition. Most types that are supported natively by absl::StrFormat() are also supported by %v. For a full list of supported types, see the StrFormat Guide.

---

Abseil Logging

08 Sep 2022

By Andy Getzendanner, Abseil Engineer

We are pleased to announce, at long last, the initial availability of the Abseil Logging library. This library provides facilities for writing short text messages about the status of a program to stderr, disk files, or other sinks (via an extension API).

The core interface is the LOG macro, which has a streaming interface like std::ostream’s:

absl::StatusOr<absl::Duration> GetUserAge(absl::string_view user_name) {
  int user_id = GetUserId(user_name);
  if (user_id == -1) {
    LOG(ERROR) << "No user found named " << user_name;
    return absl::NotFoundError(absl::StrCat("No user found named ", user_name));
  }
  return age_map[user_id];
}

The library also supports terminating the process via a severity level named FATAL:

absl::Duration GetUserAge(absl::string_view user_name) {
  int user_id = GetUser(user_name);
  if (user_id == -1) {
    LOG(FATAL) << "No user named " << user_name << " found";
    // No need for a return statement; this line is unreachable.
  }
  return age_map[user_id];
}

The CHECK macro family provides assert()-like precondition checking and process termination in all compilation modes with better error messages:

absl::Duration GetUserAge(absl::string_view user_name) {
  int user_id = GetUser(user_name);
  CHECK(user_id != -1) << "No user named " << user_name << " found";
  return age_map[user_id];
}

Read more

---

The Danger of Atomic Operations

18 Jan 2022

By Ashley Hedberg, Software Engineer

The C++ Standard provides a library for performing fine-grained atomic operations (e.g. std::atomic). Engineers sometimes reach for these atomic operations in the hope to introduce some lock-free mechanism, or to introduce clever tricks to improve performance. At Google, we’ve found – more often than not – that such attempts lead to code that is difficult to get right, hard to understand, and can often introduce subtle and sometimes dangerous bugs.

We’ve now published a guide on the danger of these atomic operations, and are publishing it to Abseil as a general programming guide. Atomic operations should be used only in a handful of low-level data structures which are written by a few experts and then reviewed and tested thoroughly. Most programmers make mistakes when they attempt direct use of atomic operations. Even when they don’t, the resulting code is hard for others to maintain.

For more information, check out The Danger of Atomic Operations.

---

SWE Book Freely Available

22 Apr 2021

Software Engineering at Google Book Availability

By Titus Winters, Tom Manshreck, and Hyrum Wright

We’re very pleased to announce that the “Software Engineering at Google” book (the Flamingo Book) is now freely available electronically under a Creative Commons license. You can get a PDF at SWE Book.

From the very beginning of this project, about three years ago, our intent has been to describe how Google thinks about Software Engineering, and to get people thinking about the same kinds of big interesting problems. We think that the best way to do that is to make sure that the content is available for everyone, so we’re providing it now, free of charge. We’re very grateful for our partners at O’Reilly for helping to make this possible (and of course we encourage you to support them and buy a physical copy if you can, etc).

Some of you may be aiming to land a job at Google in the future: we’ve heard from dozens of Nooglers that this is the handbook they needed to understand the unique and complex machine that is Google. We hope this book is useful for you.

Some of you may be running your own software companies. You’ll have different scales and problems, but hopefully you can learn from how we think about problems arising from Time and Scale, and how we evaluate the relevant Tradeoffs (these are the main themes threaded through every chapter of the book). You may want to lean on our thinking, or blaze your own trails. We hope the insights we’ve earned the hard way can make your path easier.

Some of you may know more than us. There are several topics in the book where we are still trying to find a good answer. We’re making our thinking public - why not show us where we’re wrong?

Over the past year we’ve heard from hundreds of you, all over the world, with stories about how this material has affected your practice and thinking. We’re also seeing this picked up by colleges and universities looking to modernize their discussion of software engineering topics. We’re thrilled at this reception, and very excited that we can take this next step in sharing this material.

As Nicole Forsgren told us once, “Accountants still have meetings to discuss their practices, and accountancy goes back thousands of years. Software Engineering is barely 50 years old. Give us a minute.” As an industry, and as a discipline, we’re still figuring things out. We hope that this book, in some small way, can help with that.

-Titus, Tom, and Hyrum

---