O(1), O(n) and O(#$*&!)
summary
Flame graphs and Jaeger/Tempo traces expose actual bottlenecks: an M+1 DB pattern shows repeated queries, a factorial sort crashes the OpenTelemetry container past ~10 cats, selection sort takes ~4 ms for 30 cats while merge sort drops to ~1.2 ms, and parallelizing cat image fetches yields an ≈100× speedup. Rules emerge: closer is better, don’t wait around. OpenTelemetry plus an OpenTelemetry in-memory spans exporter lets automated tests assert span counts so regressions get caught before they ship.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:04Big O complexity categories
- 2:30OpenTelemetry performance
- 3:56I/O slowness causes
- 5:21N+1 query problem
- 7:28Avoid waiting for I/O
- 8:54Parallelism in JS and Ruby
- 10:17Amdahl’s Law explained
- 12:05O(1) operations
- 12:47O(n) and collections
- 13:53Algorithmic complexity pitfalls
- 15:17O(n!) worst-case
- 17:01O(n²) sorting
- 19:33O(n log n) sorting
- 21:00Parallelizing reductions
- 23:50Enforcing performance tests
- 25:34When to stop optimizing
related talks
55mCoding with the lights ON - OpenTelemetry from code to prod
19mOops my app performance sucks... what if observability could be a game changer?
17mOpenTelemetry Looks Good To Me: Loki, Grafana, Tempo, Mimir
25mDebugging Slow Infrastructure Runs With OpenTelemetry in OpenTofu
24mUnlocking Advanced Processing Capabilities with OpenTelemetry
52mGraphQL Observability with Elastic and OpenTelemetry
32mOpenTelemetry, databases, and machine learning
58mOpenTelemetry 101