Hacker News Reader

Comment by wakawaka28 | Hacker News Reader

Why should anyone use zapcc instead of ccache? It certainly sounds expensive to save all compiler's internal data, if that is what it does.

I'm sure you must be aware, these compiler tools do not constitute a language innovation. I'd also imagine that both are not productions ready in any sense, and would be very difficult to debug if they were not working correctly.

View on HN

Zapcc can, and frequently does, speed up the compilation of single files by 20x or more in the incremental case. CCache can't do that. And it's by far the common case when compiling iteratively during development. A speedup that large is transformational to your development workflow.

ccache speeds up compilation of single files by quite a lot, by effectively avoiding unnecessary recompilation. There are distributed caches that work like ccache too. Compiling a file for a second or fiftieth time with no changes because of doing a clean build is the absolute most common case. Maybe zapcc does additional caching of compiler internal state, but I would have to look into it to see if it's actually good enough. Also, ccache works with many compilers, whereas zapcc is its own compiler. That is a huge advantage.

I have a cpp file that takes 10 seconds to compile. I change one line. How does ccache help me in this case?

When you do a clean build, it will pull that output from the cache if it has been compiled before and has not changed since. It does not technically speed up compilation of files. It bypasses compilation when it can.

ccache does not speed up compilation at all, in fact it slows it down. It only speeds up re-compilation of the same translation unit (as in, bitwise identical preprocessed source code) which is often not all that useful, especially when the local development rebuild use case is already covered by make.

ccache hardly slows anything down. It is a thin wrapper around running the compiler. You seem to kind of understand how it works, but it has multiple configurable ways to detect whether a file should be compiled. It does a LOT more than make, which does NOTHING to handle clean rebuilds or multiple builds of similar code in different locations. Unlike make, it does not rely on file timestamps alone to decide whether to rebuild an output.

The readme does a really bad job of explaining this. They are also using the wrong metrics. What’s really interesting is time to incrementally recompile after changing one header file in $LARGE_PROJECT. Single file compilation sounds like an artificial measurement and isn’t exactly painful with normal clang today. Full build measurements are rather irrelevant in a project with proper incremental setup, or even ccache. Not that I would say no to faster full builds :)

ccache only caches the individual object files produced by compiling a .cpp file.

C++ build times are actually dominated by redundant parsing of headers included in multiple .cpp files. And also redundant template instantiations in different files. This redundancy still exists when using ccache.

By caching the individual language constructs, you eliminate the redundancy entirely.

Why should anyone eat apples instead of oranges?

ccache doesn't add anything over make for a single project build.

Yes, it does a LOT more than make. You can set it up to cache files for every copy of a project in your workspace. So if you kick off 10 related builds, for example, only the files that differ will be compiled twice. Although I guess it depends on what you mean by a "single project build". Even in the case of one copy, a clean rebuild will use the cache to speed things up.

Reply on news.ycombinator.com