And it's clear that this fuzzer input is stress for Myers, not for post-processing in general.

Yes, but my read is: the report is more a Myers stress case than a post-processing stress case.

Key signals:

• The timeout stack is in myers::middle_snake and repeated Myers::run, not in postprocess.rs.
• The fuzz target amplifies cost heavily: for each input it computes Histogram and Myers, and for each algorithm it recomputes the diff three times for three post-processing modes. That is six full diff computations per fuzz iteration.
• Histogram can fall back to Myers, so bad inputs can effectively hit the Myers path more than the target name suggests.
• Post-processing has bounded local heuristics: indent sliding checks at most 100 positions, and blank-line context scans cap at 20. That can still add overhead on many hunks, but it does not look like the source of the deep recursive stack or the main timeout.

There may be real optimization opportunities, but I would separate them:

1. Myers performance/depth: the recursive divide-and-conquer can get very deep with unlucky split shapes. The current implementation recurses into the low half and iterates over the high half, so it avoids one side of recursion, but still has bad-depth cases if splits are repeatedly skewed.

2. Post-processing overhead: IndentHeuristic recomputes indentation repeatedly through the callback. A practical improvement would be caching IndentLevel per token for a postprocess run, especially for large inputs or many movable hunks.

3. Fuzz-target realism: the target is intentionally expensive because it recomputes rather than cloning/reusing one diff. That is okay for coverage, but it makes the 100-runs/60s timeout a poor proxy for real user-facing “postprocess is slow.”

So: I would not conclude that post-processing is broadly too slow from this reproducer. I would conclude that huge, adversarial, repetitive inputs can make the full diff pipeline expensive, and the fuzzer target multiplies that cost. If we wanted a follow-up performance patch, I’d look first at indent-level caching and maybe a Myers recursion-depth guard or explicit work stack.