Adventures in Efficiency and Performance
summary
Claims concrete enough to act on: libraries like parallel collections and a dot linker/optimizer exist; insertion sort beats quicksort on tiny arrays (threshold ~5,000); memory writes benefit from cache-line alignment so 64‑byte writes can be faster than single‑byte writes and padding fields can speed hot writes; hardware matters — main memory access stays ≈100 ns for decades; measurement noise is real — binary layout or even folder name can swing perf by ~20%, so start tracking and fix environments.
AI-written summary · about
chapters (13)
- 0:00Start
- 1:42EFFICIENCY VS PERFORMANCE
- 2:04EFFICIENCY = DOING LESS WORK
- 2:41PERFORMANCE = DOING IT FASTER
- 3:31ADVENTURES BEGIN!
- 3:54CAN INEFFICIENT ALGORITHM BE MORE PERFORMANT?
- 8:21LESS INSTRUCTIONS - FASTER CODE?
- 11:03CAN A SINGLE THREADED PROGRAM DO WORK IN PARALLEL?
- 13:45CAN FAILED CPU SPECULATIONS BE GOOD?
- 15:35"DATE" MAKES A DIFFERENCE
- 22:44PERFORMANCE RECIPES DO NOT AGE WELL.
- 27:28PATTERN BET
- 30:38MADE A CHANGE AND YOUR APP BECAME FASTER?
related talks
51mDesigning for Performance
56mWhy Data Access Patterns Have Always Mattered
01h 09mThere's Treasure Everywhere
01h 02mFastware
01h 00m“When a Microsecond Is an Eternity: High Performance Trading Systems in C++”
56mWrite Fast Code Like a Native
01h 04mWe Live in Interesting Times
57mInvited Talk: Bridging Safety and Performance