What is Zapcc?

Zapcc is a C++ compiler based on clang, designed to perform faster compilations.

What is the typical acceleration of Zapcc?

Typically re-compilations are 10x-50x faster (see 40x example Boost.Math), and full builds are 2x-5x faster (see 4x example of WebKit).

How are you testing Zapcc?

We use internally-written tests with the LLVM LIT testing tool and build bots with many open-source libraries and projects including Clang/LLVM, deal.IIEigen, Folly, Mesos, MongoDB, OpenCV, Paraview, PCL, POCO, Quantlib, QT, Trilinos, VCSN, Webkit and more.

Do you sacrifice runtime performance?

No. From the various tests we run, run-time performance of Zapcc generated code is equivalent to the code generated by clang.

Is Zapcc Clang compatible?

Yes, zapcc is based on heavily-modified clang code.

Is Zapcc GCC compatible?

Yes, to the extent clang is gcc compatible.

Do you support the sanitizers?

Currently, no.

My project does not compile with Zapcc!

Please make sure first your project compiles successfully with Clang. If your project does not compile with Clang, Zapcc, being based on Clang, will not be able to compile any more than clang.

Which operating systems do you support?

We have released Zapcc for Linux x64.

What is the “trick”?

Zapcc uses in-memory compilation cache in client-server architecture, remembering all compilation information between runs. ‘zapcc’ is the client while ‘zapccs’ is the server. Each zapcc run will reuse an existing server, or if none available will start a new one.

How zapcc is different from precompiled headers?

Precompiled headers requires building your project to the exact precompiled headers rules. Most projects do not bother with using precompiled headers. Even then, precompiled  headers do not cache as much as zapcc. Zapcc works within your existing build.

Precompiled headers are currently ignored by Zapcc.

How zapcc is different from C++ modules?

Modules are not yet standard, rarely used and do not support well legacy code and macros found in most existing C++ code, such as Boost. Modules require significant code refactoring in bottom-up approach everything or are slow. Even then, modules do not cache template instantiations and generated code that are specific to your code like zapcc does.

How much memory does Zapcc use?

To avoid killing the server by using endless memory, Zapcc server has a memory limit and will automatically reset after reaching it, restarting with an empty cache and low memory usage. The memory limit is set under [MaxMemory] at bin/zapccs.config, and you can change it to optimize memory usage and the number of servers (“make -j”) you plan to use. Usually, you should not set the -j parameter to more than the number of physical cores + 2. This is especially important for Intel CPU with hyper-threading enabled, which report twice the number of physical cores. In such cases, Zapcc may run faster with fewer servers, each using a higher memory limit.

Memory is quite cheap and we recommend allocating enough physical memory to all Zapcc servers you would like to run.

How do I free the memory Zapcc uses?

To kill all servers at once run

zapcc -cc1 -reset-server


kill zapcc

Do you rely on ccache, distcc, warp or the like?


By how much do you expect Zapcc to accelerate compilation times?

This depends on the complexity of the header files vs. the complexity of the source files. It can range from no acceleration at all for plain C projects to x2-x5 for build-all of heavily templated projects, up to cases of x50 speedups in developer-build incremental change of one file.

As a reference number, Zapcc accelerates clang build-all about x2 faster compared to building clang using clang.

Will Zapcc accelerate C projects as well?

No, caching is disabled for C files.

Build shared and static configurations separately for better performance

Some build system build each file both for shared and static configurations, in the following order:

  • File 1 static
  • File 1 shared
  • File 2 static
  • File 2 shared

The change from static to shared and vice verse invalidates the Zapcc cache on every compile, resulting in bad build performance.  To solve this, build the different configurations separately, for example

>configure --disable-shared && make && configure --disable-static && make

Similarly, try not to change other flags between compilations as most flag changes will result in a cache invalidation and reset.

Macro-dependent headers

Headers that depend on changing macros which may change during compilations will result in cache resets and performance hits. Consider defining macros in command line to make sure consistent definition throughout the cache. For example, for Boost.Threads:


Why did you create Zapcc?

We love C++. It’s one of the best programming languages out there. However, C++ compilations are getting longer and longer, due to the complexity of the language and especially due to templated header files. We identified an opportunity to improve, and that is why we started developing Zapcc.

Who’s behind this project?

A team led by Yaron Keren and Ophir Herbst, seasoned high tech entrepreneurs. The company is Ceemple Software Ltd., based in Israel.

If there is anything else you wish to know, please don’t hesitate contacting us.