When to profile before you rewrite a module
Rewrite meetings feel productive because they produce diagrams. Profiling meetings produce awkward silence while someone runs a harness. Still, the order matters.
Profile first when the slowdown correlates with a deploy
Library upgrades, configuration toggles, and accidental debug logging often show up as a single hot frame. A rewrite would miss a one-line fix.
Profile first when CPU is high but code “looks fine”
Readable code can hide accidental quadratic loops—especially pandas or ORM paths. Measure before you split services.
Consider rewrite first when the module has no tests and no owner
Profiling tar pits exist: code nobody understands and nobody wants to touch. If bus factor is zero and the module is small, a bounded rewrite with new tests can be cheaper—after you spend one day confirming the module is actually on the hot path.
Consider rewrite first when requirements changed structurally
If you now need streaming instead of batch, patches may accumulate into a rewrite anyway. Profile to salvage pieces (validators, serializers), not to defer architecture conversation.
Practical rule we use with clients
Spend one business day on reproduction and a baseline profile. If the top hotspot is inside the suspect module and explains most of the regression, patch. If profiles scatter time across many callers, schedule a design review instead of a rewrite sprint.