Points worth noting (from that thread and elsewhere): Broadly speaking, it's about the same as C++. Helpfully, there's a live thread about the matter on r/rust. Rust doesn't compile very quickly at the moment. He mentioned that a decent size game should compile either instantly or in a couple of seconds So we know how to solve this in principle, we just aren't putting the pieces together. Yet, how much of the code really needs to be optimized that well? And how much of that code needs to be recompiled that much? Of course none of these are C++ and they also don't optimize as well etc. We also used to have true separate compilation, but that appears to be falling out of favor. Then there are Smalltalk and Lisp systems that are always up and pretty much only ever compile the current method. It compiled a generated 200KLOC file (lots of small functions) in around 200 ms. Spurred on by Jonathan Blow's musings on compile times for Jai, I started tinkering with tcc a little. I just recently talked to someone whose Swift framework(s) were compiling at roughly 16 lines per second. Yes, and I mean "we" as in "this industry". Places that don't make incremental builds 100% reliable drive me crazy and waste so much developer time. You don't get a fast build process for free, but if the team makes it a priority, alot can be done.ĮDIT: Times mentioned were for a full build, often you rarely due a full build, incremental builds should be majority. Starting with a full build that initially takes hours and it shrinking to < 15-20 minutes and better seems pretty par for the course for truely large C++ projects. There is even a older book, Large-scale C++ Design, that is specifically about this point. Epic's build system is a pretty good example. Most of the projects I've worked on have been larger than Chrome, I've seen the compile time for BioShock Infinite go from 2 hours down to 15 minutes with serious work on header use, precompiled headers, and all the other tricks people use. Few people enjoy 'improving the build', it often touches everything, and requires discipline to keep it working. Not to take away from your point, but in my experience the vast majority of C++ build pipelines even at major companies can still be improved. While these systems have scaled C++ development far further than ever thought possible, and are remarkable in the engineering achievement therein, we just need to step back once in a while and ask ourselves: I've worked with a lot of build systems over the years, including Google's internal build system open sourced as Bazel. so file and 1.2MB startup executable-that's a 18x blowup. A debug build of V8, which is just a small subsystem of Chrome, will generate about 1.4GB of. Oh, and at the end of the day, the linker has to clean up the whole mess, discarding the vast majority of the compiler's output due to so many duplicated functions. Moreover, because the C++ compiler needs to see full class definitions to, e.g., know the size of an object and its inheritance relationships, we have to put the main meat of every class definition into a header file! Don't even get me started on templates. However, to actually have the C++ compiler do inlining at compile time (LTO be damned), we have to put the definitions of inline functions into header files, which greatly increases their size and processing time. As an application grows, the number of header files grows because, as any sane and far-thinking programmer would do, we split the complexity up over multiple header files, factor it into modules, and try to create encapsulation with getter/setters. How did we get here? Well, C++ and its stupid O(n^2) compilation complexity. Even on a hefty workstation, a full build is a go-for-lunch kind of interruption. TBH I don't remember toughing out a full build without resorting to goma. Without the distributed build, a from-scratch build of Chrome will take at least 30 minutes on a Macbook Pro-maybe an hour(!). Full disclosure: I work for Google on Chrome.Ī Chrome build is truly a computational load to be reckoned with.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |