If you're in trouble and cannot find an answer to a question which goes beyond Stack Overflow...
If you have a not-so-usual solution for your problems but need to justify it to your boss...
If you like to think on your own rather than blindly follow "common wisdom" and "profound truth"...
...then 'No Bugs' Hare on Soft.ware might be the right place for you.
Your mileage may vary. Batteries not included

Assorted Rants Tagged ‘Overload’, page 1:

‘Speedy Gonzales’ Serializing (Re)Actors via Allocators

Quote: “Allocator-based serialization for (Re)Actors is extremely fast (for x64 – around tens of ms per 100MB of state)”
Another Quote: “Per-(Re)Actor allocators can be implemented without any changes within (Re)Actor itself (i.e. all the necessary changes can be confined to Infrastructure Code).”
[]

Allocator for (Re)Actors with Optional Kinda-Safety and Relocation

Quote: “‘Safe with relocation’ mode will allow us to eliminate dreaded ‘external fragmentation’ – which tends to cause quite a bit of trouble for long-running systems”
Another Quote: “For a long while, I have been a strong proponent of message-passing mechanisms over mutex-based thread sync for concurrency purposes”
[]

The Importance of Back-of-Envelope Estimates

Quote: “trying to optimize out a 3e-7 performance hit is very rarely worth the trouble.”
Another Quote: “With 4S/4U boxes having typical MTBFs of 3–5 years, the next question we should ask ourselves, is “Hey, will we really be able to write software which crashes much more rarely than that?””
[]

Ultra-fast Serialization of C++ Objects

Quote: “in both these cases we can be 100% sure that we’ll be deserializing this state on the executable which is identical to the executable which serialized the state.”
Another Quote: “Even when comparing with home-grown code with per-field serialization, our Ultra-Fast Serialization still wins (up to 1.5x-2x) “
[]

Some Big-Os are Bigger Than Others

Quote: “Strictly speaking, for real-world computers, every algorithm which completes in a finite time can be said to be O(1)
Another Quote: “now the difference because of unfortunate ‘jumps’ over (uncached at the time) memory can lead to a 100x+ (!) performance difference. However, it is still O(1) and is rarely taken into account during performance analysis”
[]