<div dir="rtl"><div dir="ltr">Hi Chris,</div><div dir="ltr"><br></div><div dir="ltr">I am the prinicipal developer of zapcc and can add some more tech details. zapcc is heavily-modified clang (the diff is about 200K) with additional code outside the llvm/clang codebase. zapcc operates in a client-compilation server mode. The compilation server (think of it as clang -cc1) stays in memory and accepts compilation commands from the driver. The client runs until cc1_main() which communicates with the server rather than rerunning another clang as usual. </div><div dir="ltr"><br></div><div dir="ltr">zapcc makes distinction between two classes of source files, the "system" ones of which all compilation state is kept in memory and the "user" ones whose compilation state is removed once compiled. The programmer can select which are the "user" files by wildcards set in a configuration files. The default of user is .c .cpp .cxx .CC files but it could easily be all files in /home/user/yaron or whatever. It is expected that the system files are non-changing (such a change will not be recognized anyhow until server restart) while the user files are the ones to be modified. As an example, you could have llvm/lib/MC/MachObjectWriter.cpp as the "user" file so every other file compilation result would be kept in memory.</div><div dir="ltr"><br></div><div dir="ltr">Not only a header file is parsed once but all its templates instantiations *and* generated code are kept memory ready for the next compilation. zapcc is very carefull to undo anything releated to the 'user' files in clang/LLVM data structures,This is very very complex, which is why zapcc is not yet ready for public beta. We prefer to release a more reliable product rather than waste your time.</div><div dir="ltr"><br></div><div dir="ltr">There are limitations with this approach, as previously declared entities are still visible in subsequent compilations, a limitation we hope to address someday, not in the near future. With good quality modern codebase such clashes are rare. In the LLVM/clang codebased there are just a few clashes which can be easily fixed by renaming one of the clashing entities. Some of the renaming would be according to the new codestyle anyhow... In such cases zapcc automatically resets the compilation cache and retries compilation before giving up. It also resets if compilation flags change or in some situations it finds out it can't undo the compilation.</div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr">Having everything ready in-memory saves time, especially where the headers are much more complex than the source code. With a short C++ program using boost::numeric, boost::graph etc or Eigen, we see a 10-50x speedup. We had some code examples on the web site which I asked to be currently removed now until we can provide you with a beta release so that the results could be independently replicated. These may be considered best-case examples but are actally useful for programmers modifying and rebuilding a smaller program based on heavy templated C++ infrastructure. </div><div dir="ltr"><br></div><div dir="ltr">For full-build LLVM compilation we don't yet have full results as not all zapcc bugs are solved, but we do see about 1.5x speedups building until 55% build or so. This timing includes some linking and tablegenning which just the same using zapcc, so compilation speedup is actully somewhat better.</div><div dir="ltr"><br></div><div>We haven't compared with precompiled headers as they are really not equivalent. Using precomp headers is non-trivial change to a project build and will not always help build time ,depending on include patterns. I'm not sure precomp headers would benefit LLVM build time. OTOH, zapcc builds the project as-is without redesign, with the exception of renaming name clashes, a trivial refactoring.</div><div dir="ltr"><br></div><div>Hoping to release a beta version soon,</div><div><br></div><div>Yaron</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div dir="ltr">2015-05-23 21:05 GMT+03:00 Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span>:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Does anyone know anything about this?<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.zapcc.com&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=0Vm6_KOWg-M81V3GXXfBM_Lmrrl19bDq3tNY8uBh0j0&s=DS1_cX_BfI-VIlVQ1YNmB-OEdqOnUkPB0s57ebXYD_Q&e=" target="_blank">http://www.zapcc.com</a><br>
<br>
-Chris<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>