# Bazel caching and compressed debug info

DevFeed: [Bazel caching and compressed debug info](<https://devfeed.tech/articles/bazel-caching-and-compressed-debug-info-25410.md>)

Original publisher: [Read original article](<https://smileykeith.com/2025/02/14/compressed-debug-info/>)

Author: Keith Smiley

Published: 2025-02-14T18:00:00Z

Content type: tutorial

Language: en

Sources: [Keith Smiley](<https://devfeed.tech/sources/keith-smiley.md>)

Topics: [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [LLVM](<https://devfeed.tech/topics/llvm.md>), [gcc](<https://devfeed.tech/topics/gcc.md>), [C](<https://devfeed.tech/topics/c.md>)

Tags: [bazel](<https://devfeed.tech/tags/bazel.md>), [build](<https://devfeed.tech/tags/build.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [caching](<https://devfeed.tech/tags/caching.md>), [clang](<https://devfeed.tech/tags/clang.md>), [cmake](<https://devfeed.tech/tags/cmake.md>), [config](<https://devfeed.tech/tags/config.md>), [configuration](<https://devfeed.tech/tags/configuration.md>)

## AI overview

This article explains how compressing debug information can reduce C and C++ binary sizes and improve Bazel remote-cache efficiency. Using llvm-objcopy, the example reduces a roughly 536 MB binary to about 290 MB, and the authors report nearly 60% fewer cache reads after deployment.

## Source excerpt

One of bazel's most attractive features is the ability for it to remotely cache artifacts to reduce unnecessary work for large builds. Unfortunately users quickly discover this comes with non-trivial financial and bandwidth implications. There are many ways, of varying difficulty, to try and improve your cache usage. From breaking unnecessary dependencies, to adding larger local storage for CI workers, builds without the bytes, build avoidance, etc. For codebases with lots of C or C++ one of the potentially easiest wins is to enable compressed debug information1. Let's look at an example from our codebase. Looking at the size of a non-trivial C++ binary built with -g -O2 (similar to cmake's RelWithDebInfo configuration), or binary clocks in at ~530mbs: % du -sh bin 536M bin To get a sense of what percentage of this binary is debug info, we can use llvm-objcopy to strip the debug info entirely: % llvm-objcopy --strip-debug bin strippedbin % du -sh strippedbin 159M strippedbin This shows us that almost 70%(!!) of the binary size is taken up with debug info. In release configurations we can eliminate this entirely with bazel's --strip argument, but for developer builds, or other use cases where you need debug info, we can still improve this. If we use llvm-objcopy again, this time to compress the debug info, we can immediately see our potential gains: % llvm-objcopy --compress-debug-sections bin compressedbin % du -sh compressedbin 290M compressedbin This shows us we can get an almost 50%(!!) improvement in binary size in this example. To enable this in bazel, assuming you're using a relatively recent version of gcc or clang, you can add something like this to your .bazelrc2: build --enable_platform_specific_config build:linux --copt=-gz --host_copt=-gz build:linux --linkopt=-gz --host_linkopt=-gz In practice we saw cache reads drop by nearly 60% when we rolled out this change. Reducing binary size with this approach has a lot of benefits, but it's even more pronounced