[agent327]

> What value do you think something like zapcc brings that tools like ccache haven't been providing already?

It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instantiation costs in each object file.

[motorest]

> It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instantiation costs in each object file.

I'm afraid this feature is at best a very minor improvement that hardly justifies migrating a whole compiler. To be blunt, it's not even addressing a problem that exists or makes sense to even think about. I will explain to you why.

I've been using ccache for years and I never had any problem getting ccache to support template code. Why? Because the concept of templates is ortogonal to compiler caches. It matters nothing, if you understand how compiler caches work. Think about it. You have the source file you are compiling, you have the set of build flags passed to the compiler, and you have the resulting binary.

That's the whole input, and output.

It's irrelevant if the code features templates or not.

Have you checked if the likes of zapcc is fixing a problem that actually doesn't exist?

[agent327]

> I'm afraid this feature is at best a very minor improvement that hardly justifies migrating a whole compiler.

Here are some performance numbers: https://www.phoronix.com/news/Zapcc-Quick-Benchmarks

> To be blunt, it's not even addressing a problem that exists or makes sense to even think about. I will explain to you why.

Do you talk down to people like this IRL as well?

> I've been using ccache for years and I never had any problem getting ccache to support template code.

What I said is that zapcc has a different approach that offers even more performance benefits, answering the question of what zapcc offers that ccache doesn't offer.

> if you understand how compiler caches work. Think about it.

There's no need to use "condescending asshole" as your primary mode of communication, especially when you are wrong, such as in this case.

[motorest]

> Here are some performance numbers: https://www.phoronix.com/news/Zapcc-Quick-Benchmarks

If you look at the benchmarks you just quoted, you see cache-based compilations outperforming zapcc in quite a few tests. I wonder why you missed that.

The ones that ccache fares as well as builds that don't employ caching at all are telling. Either ccache was somehow not used, or there was a critical configuration issue that prevented ccache from caching anything. This typically happens when projects employ other optimization strategies that mess with ccache, such as pipelining builds being enabled or extensive use of precompiled headers.

The good news is that in both cases these issues are fixed by either by actually configuring ccache or disabling these other conflicting optimization strategies. To be able to tell, it would be necessary to troubleshooting the build and take a look at ccache logs.

> Do you talk down to people like this IRL as well?

Your need to resort to personal attacks is not cool. What do you hope to achieve, other than not sounding like an adult?

And do you believe that pointing out critical design flaws is "talking down to people"?

My point is very clear: your baseline compiler cache system, something that exists for two decades, already supports caching template code. How? Because it was never an issue to begin with. I explained why: because a compiler cache fundamentally caches the resulting binary given a cache key, which is comprised of data such as the source file provided as input (basically the state of the translation unit) and the set of compiler flags used to compile it. What features in the translation unit is immaterial. It doesn't matter.

Do you understand why caching template code is a problem that effectively never existed?

> What I said is that zapcc has a different approach that offers even more performance benefits, answering the question of what zapcc offers that ccache doesn't offer.

It's perfectly fine if you personally have a desire to explore whatever idea springs to mind. There is no harm in that.

If you are presenting said pet project as any kind of solution, the very least that is required of you is to review the problem space, and also perform a honest review of the solution space. You might very well discover that your problem effectively does not exist, because some of your key assumptions do not hold.

I repeat: with pretty basic compiler caches, such as ccache which exists for over two decades, the only thing you need to do to be able to cache template code is to install ccache and set a flag in your build system. Tools such as cmake already support it out of the box, so onboarding work is negligible. Benchmarks already show builds with ccache outperforming builds with the likes of zapcc. What does this tell you?

[jhasse]

It isn't only about template code. zapcc speeds up compilation when there's no cache. I tried it 10 years ago and it really reduced build times from minutes to seconds. For full builds.

[motorest]

> It isn't only about template code. zapcc speeds up compilation when there's no cache.

Someone else in this thread already pasted benchmarks. The observation was, and I quote:

> Zapcc focuses on super fast compile times albeit the speed of the generated code tends to be comparable with Clang itself, at least based upon last figures.