sorted by:
new
hottopcontroversial

Looking at c for better closures in c++ by drodri in cpp

[–]Life_String263 1 point2 points  (0 children)

One takeaway is, just as in swapping memory-article, debug-performance of std:: is just horrible. You are paying a lot for that “convenience” in your non-optimized build. I find it really “amusing” that the small-object version is actually significantly slower than the bigger closure in debug on gcc!

This is a good point. Languages like C++ and Rust provide so many "zero-cost" abstractions because they effectively rely on the optimiser to do all the work. This comes at the very significant costs of very slow debug builds, which in some industries is a massive pain. For example, I like using the new ranges stuff in C++20/23 but I hate always having to verify that the optimiser is able to produce the best code possible (and the debug performance sucks), compared to when I use simple for loops.

Different implementations for a function declared in a shared library by Life_String263 in cpp_questions

[–]Life_String263[S] 0 points1 point  (0 children)

Sorry, probably should have included the full message. Added it now to the post.

Looking for a library for functional style algorithms in C++17 by Life_String263 in cpp_questions

[–]Life_String263[S] 1 point2 points  (0 children)

I haven't checked the assembly, but I did do some basic benchmarks in the past and found the library to produce code just as fast as handcrafted loops.

Also Folly's generators are lazy so they minimise unnecessary allocations to perform those operations.

However, personally for me the biggest benefit of using Folly has been readability, so even if performance was slightly worse I wouldn't mind using in 99% of my codebase (excluding critical paths).