"Less Slow C++" offers practical advice for improving C++ build and execution speed. It covers techniques ranging from precompiled headers and unity builds (combining source files) to link-time optimization (LTO) and profile-guided optimization (PGO). It also explores build system optimizations like using Ninja and parallelizing builds, and coding practices that minimize recompilation such as avoiding unnecessary header inclusions and using forward declarations. Finally, the guide touches upon utilizing tools like compiler caches (ccache) and build analysis utilities to pinpoint bottlenecks and further accelerate the development process. The focus is on readily applicable methods that can significantly improve C++ project turnaround times.
The GitHub repository "Less Slow C++" by Ashvardanian presents a collection of techniques and best practices aimed at improving the compile time performance of C++ projects. The author emphasizes that while C++ offers powerful features and performance advantages, it often suffers from notoriously long compilation times, which can hinder developer productivity and slow down the development cycle. The repository serves as a guide to mitigate this issue, covering a wide spectrum of optimization strategies.
The strategies discussed are categorized into several areas. A major focus is on optimizing header files. This includes minimizing the content of header files to only essential declarations, favoring forward declarations whenever possible, and employing the pimpl idiom to hide implementation details and reduce dependencies. Precompiled headers are also explored as a crucial tool for accelerating the compilation process by caching previously compiled header information.
Another area of concern addressed is the efficient usage of templates. The author acknowledges the potential for templates to introduce significant compile-time overhead due to code instantiation. Techniques for mitigating this overhead include the use of external templates, explicit instantiation, and factoring out common template code into base classes.
The repository also delves into build system optimizations. While not directly related to the C++ language itself, the build process significantly impacts compile time. Recommendations include utilizing parallel compilation through appropriate build system flags and exploring tools like ccache to cache compilation results, avoiding redundant compilation steps.
Beyond these core areas, the guide touches upon other factors that can influence compile time. The choice of compiler and its optimization flags can have a noticeable impact. Furthermore, judicious use of the C++ standard library, understanding its implementation details and potential performance bottlenecks, can also contribute to faster compilation. The author also advises on careful consideration of code style and structure, as excessively complex or deeply nested code can burden the compiler. Finally, profiling the compilation process itself is advocated as a method for identifying and addressing specific bottlenecks. The overall aim of the repository is to provide a comprehensive resource for C++ developers seeking to optimize their projects for faster compilation and improved development workflow.
Summary of Comments ( 18 )
https://news.ycombinator.com/item?id=43727743
Hacker News users discussed the practicality and potential benefits of the "less_slow.cpp" guidelines. Some questioned the emphasis on micro-optimizations, arguing that focusing on algorithmic efficiency and proper data structures is generally more impactful. Others pointed out that the advice seemed tailored for very specific scenarios, like competitive programming or high-frequency trading, where every ounce of performance matters. A few commenters appreciated the compilation of optimization techniques, finding them valuable for niche situations, while some expressed concern that blindly applying these suggestions could lead to less readable and maintainable code. Several users also debated the validity of certain recommendations, like avoiding virtual functions or minimizing branching, citing potential trade-offs with code design and flexibility.
The Hacker News post titled "Less Slow C++" (https://news.ycombinator.com/item?id=43727743) sparked a discussion with a moderate number of comments, largely focusing on the practicality and nuances of the advice offered in the linked GitHub repository.
Several commenters appreciated the author's effort to collect and present performance optimization tips. One user highlighted the value in consolidating such information, especially for those newer to C++, acknowledging that while experienced developers might be familiar with many of the tips, having them readily available in one place is beneficial.
However, a recurring theme in the comments was the caution against premature optimization. Multiple users emphasized that focusing on code clarity and correctness should precede optimization efforts. They argued that optimizing without proper profiling and understanding of actual bottlenecks can be counterproductive, leading to more complex code without significant performance gains. One commenter even suggested the title should be "Faster C++," as "Less Slow" implies a focus on fixing slowness rather than writing efficient code from the start.
Some commenters delved into specific points from the GitHub document. There was discussion around the use of
std::vectorversusstd::array, pointing out thatstd::arrayis often preferable for small, fixed-size collections due to its avoidance of heap allocation. Another discussion centered on the advice to avoid exceptions, with some agreeing on their performance overhead, especially when thrown frequently, while others argued that exceptions are crucial for error handling and shouldn't be dismissed solely for performance reasons.The topic of inlining also garnered attention. While the GitHub document recommends strategic use of inlining, some commenters elaborated on the compiler's role in inlining decisions. They highlighted that modern compilers are often better at determining which functions to inline, making explicit inlining less necessary and sometimes even detrimental.
Finally, a few commenters shared their own experiences and preferred optimization techniques, adding further depth to the conversation. One mentioned the importance of considering data locality and cache efficiency for performance-critical code.
Overall, the comments section provides a balanced perspective on C++ optimization. While acknowledging the usefulness of the compiled tips, the discussion emphasizes the importance of careful profiling, prioritizing code readability, and understanding the trade-offs involved in different optimization strategies. It serves as a reminder that blindly applying performance tweaks without proper consideration can often do more harm than good.