3 ms·
I agree that micro-optimization obsession is a problem in the C++ community, but sometimes it is useful and then it's nice to have the option. Personally, I ha
by imron 11y ago
I agree that micro-optimization obsession is a problem in the C++ community, but sometimes it is useful and then it's nice to have the option.
Personally, I have my own custom hashmap which provides a 10%-15% performance improvement over the std one for my use case, and I also have custom mutex/thread code similar to the one listed in this library because it provides better performance when no other thread has the lock, and avoids needing to compile/link against the boost equivalent which adds seconds of compile time to any file that includes it.
These are all optimisations that I have tested and profiled though.
- pjmlp 11y agoWhich is all fine if you are coding for scenarios where every ms counts like you say. The problem I see is when doing applications where doing the work in 100ms or 1s doesn't matter at all. Yet one will be discussing about bounds checking impact, if i++ or i = i + 1 generate the same code and many other micro-optimizations. For the type of work I do, I always embraced the STL and never though a second about those issues, yet I was able to fulfill the expectations.