"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.
Bazel's next generation focuses on improving build performance and developer experience. Key changes include Starlark, a Python-like language for build rules offering more flexibility and maintainability, as well as a transition to a new execution phase, Skyframe v2, designed for increased parallelism and scalability. These upgrades aim to simplify complex build processes, especially for large projects, while also reducing overall build times and improving caching effectiveness through more granular dependency tracking and action invalidation. Additionally, remote execution and caching are being streamlined, further contributing to faster builds by distributing workload and reusing previously built artifacts more efficiently.
Hacker News commenters generally agree that Bazel's remote caching and execution are powerful features, offering significant build speed improvements. Several users shared positive experiences, particularly with large monorepos. Some pointed out the steep learning curve and initial setup complexity as drawbacks, with one commenter mentioning it took their team six months to fully integrate Bazel. The discussion also touched upon the benefits for dependency management and build reproducibility. A few commenters questioned Bazel's suitability for smaller projects, suggesting the overhead might outweigh the advantages. Others expressed interest in alternative build systems like BuildStream and Buck2. A recurring theme was the desire for better documentation and easier integration with various languages and platforms.
This video demonstrates the incredibly fast incremental compilation of the Zig self-hosted compiler. By making a small, seemingly insignificant change to a source file within the compiler's codebase and rebuilding, the video showcases a rebuild time of just around 25 milliseconds. This highlights Zig's efficient build system and its focus on fast iteration times, a key advantage for developer productivity.
Hacker News users generally praised the Zig compiler's fast incremental compilation demonstrated in the video. Several commenters highlighted the impressive speed and how it contributes to a positive developer experience. Some pointed out that while the demo is compelling, real-world project builds with dependencies might not be as instantaneous. Others discussed the potential of Zig's self-hosting capability and build system, comparing it favorably to other languages and build tools. A few users also expressed interest in Zig's memory management and safety features. There was some discussion about the practical limitations of incremental compilation and the importance of understanding its inner workings.
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.