Hi @ChuanqiXu The number has increased from 1.18x to 1.5x speed-up compared to PCH and by extension, 3x compared to the standard non-PCH. comparison.
On 32-thread 14900hx, PCH support has improved remarkably as the first time I compared, it took 5:50 compared to non-PCH 7:33. While now it takes 3:41 with latest commit build and 4:14 with distro clang-20 on Ubuntu. However, hu build takes 2:28.
In the latest HMake commit, I added support for producing a script for command-line support for IPC compilations using HMake generated IPC mod-map binary file. Then I used this feature to test why it was taking more than 1 minute for some hu. Turns out, it was a bug in my own IPC implementation in Clang.
Now, HMake compiles 2911 hu from previous >2500 and it takes just 9s on my 32-thread 14900hx.
And again, this is not the end of the road. We could get 2x build speed-up. ( Enabling and Resolving DeDuplicationWarnings::YES).
Touching clang/lib/Sema/Sema.cpp shows 1.3x speed-up (end-to-end, including linking) compared to PCH. And I believe this is on lower side with average being 1.5x as well.
To use ccache, pre-processing needs to be done to get the hash of the compilation. As shared previously, with hu, this generates, 6x less data. Since all 2911 HU compilations now complete in 9 seconds, the preprocessing step should be roughly 2x faster, particularly on low-thread machines. There is also an opportunity to eliminate process-launch overhead entirely: we can ask the compiler to return the hash directly, and if it matches a cached entry, kill the process immediately; otherwise signal the compiler to continue and then store the output.
@AaronBallman I mentioned in the meeting that currently there is no standard compilation database that is supported by the 3 of the build-system, compiler and the language-server.
This is the first draft of my proposal that I believe is extremely easy (less than a week) to support for both of the IDE and the clangd. Your workflow would be to just open the hmake.cpp file in the IDE as HMake project file. This is another chicken and egg situation. Once HMake gets green signal here, I would add support for this and complete the draft(submit the proposal to SG-15). The concept is that we serialize a hash-map that has include-name/import-name mapped to the file on the disk.
I would like to request build-system maintainers/implementers @ben.boeckel @petrhosek @rnk to do a detailed evaluation of my software. I think any potential CMake replacement should not be adopted without a detailed 6-7 day trial / evaluation. Similarly, it should not be rejected without such. I look forward to the feedback. Also, its not like that there is any else in the line with complete C++20 modules support. The requirement for such a software to be an already established software is not a constructive argument.