I noticed that the 2015 mailing list post says .c files are cached, so some time between then and the 2018 public release it was disabled for C.
If I had to guess, the actual parsing pass is always going to be a lot less complex for C vs C++, so a simpler approach like ccache’s may get similar gains for less overhead generating & maintaining the actual cache.
I agree. I push caching as the general rule if checking if it’s in the cache costs less than the time to compile the file. I’d think that was true for most languages.
Wow. The performance of this thing is nuts. Loving it.
For more details about “how” zapcc caches (at a high level), there are some talk slides in a PDF in the repo: https://raw.githubusercontent.com/yrnkrn/zapcc/51f37ca2b46b48862d7dec4010f06f50483433d9/docs/zapcc/catc17-zapcc-an-accelerating-c-compiler.pdf
That’s great. Thanks for the link!
No worries. I got to the end of the README and went digging around for some more high-level details of what zapcc was doing, noticed that.
…any idea why? I wouldn’t expect a huge speedup, because C headers aren’t entirely insane, but it seems an odd decision.
I noticed that the 2015 mailing list post says .c files are cached, so some time between then and the 2018 public release it was disabled for C.
If I had to guess, the actual parsing pass is always going to be a lot less complex for C vs C++, so a simpler approach like ccache’s may get similar gains for less overhead generating & maintaining the actual cache.
I agree. I push caching as the general rule if checking if it’s in the cache costs less than the time to compile the file. I’d think that was true for most languages.