rseng-performance-profiling

# Performance profiling and optimization The cardinal rule: never optimize unprofiled code. Intuition about where research code spends time is wrong often enough that acting on it wastes effort and adds complexity to the wrong places. The discipline is a loop: measure, find the dominant cost, fix only that, measure again, stop when it is fast enough for the science. "Fast enough" is a research judgment - a one-off analysis needs no tuning; a per-particle inner loop run for months justifies serious work. ## Profile first - Whole-program view: a sampling profiler (py-spy for Python: `py-spy top --pid` on a live process or `py-spy record` for a flame graph) shows where time actually goes with negligible overhead and no code changes. Language-native equivalents: perf (compiled code), Rprof (R), @profile/BenchmarkTools (Julia). - Line/function view once a hotspot is known: cProfile+snakeviz, line-profiler, or the IDE's profiler. - Memory matters separately: allocation churn and swapping look like CPU slowness; profile memory when RSS grows or the machine swaps. - Profile REPRESENTATIVE inputs at meaningful scale - toy inputs have different hotspots than production ones. Report findings as fractions ("68% of runtime in distance_matrix"), not feelings; the fraction bounds the possible speedup (Amdahl's law) and justifies - or kills - the optimization. ## Optimize in payoff order 1. Algorithmic: a better algorithm or data structure beats any micro-optimization;...