3 ms·
The above is commonly encountered, but not good advice. Most important, defend your hot path against incursions. E.g., don't pass smart pointer arguments aroun
by ncmncm 4y ago
The above is commonly encountered, but not good advice.
Most important, defend your hot path against incursions. E.g., don't pass smart pointer arguments around on hot paths. That is what matters.
New language features are not slower than old features. But there are slow constructs to use carefully. Which they are will always surprise you, usually pleasantly. For example, almost everything around lambdas is fast, fast, fast, except =capture.
Measure often. Look for surprises.
- jcelerier 4y ago> Don't pass smart pointer arguments around on hot paths. oh this so much.. I remember optimizing a particle system which would copy a shared_ptr for each particle on every update operation... IIRC just switching to references ended up being 10+ times faster
- latency-guy2 4y agoIf you can design your system so you rarely if ever use pointers, that would be the single best thing you can do for your C++ codebase I like to enlighten my interns every summer about the reality of pointers, and how much of a noob trap they are, and that yes, their professor lied to them in some ways
- pclmulqdq 4y agoI literally said not to construct or destruct smart pointers on the hot path. Also, my experience with lambdas has been otherwise. There are a lot of cases where lambdas need a heap allocation when you otherwise wouldn't. However, being able to use FP ideas can make up for that.
- ncmncm 4y agoMy objection is to the expression "C-like". That does not correctly distinguish what is fast from what isn't, and instead promotes a harmful myth. A lambda needs a heap allocation only if any of its captures do.