This was executed:

  $ latexdiff report_old.tex report_new.tex > report_diff.tex

After 11 hours the process is still running hard with CPU pegged
around 99% according to /top/. CPU fan is running which also indicates
hard work is being done. There is no output to indicate how much
progress has been made.

When compiled, the document yields 13 pages in PDF form. I do not
imagine that 11+ hours is reasonable for that volume. Bug fixes and
enhancements are needed.

 ① There is likely some kind of faulty logic such as an endless loop
 ② A progress indicator is needed
 ③ A detailed debug log is needed
 ④ Periodic assessments should be made throughout the processing as to
    whether reasonable progress is being made. If an hour is spent on a
    normal sized paragraph, the tool should abort and perhaps give an
    indication of which segment of text is exceeding time
    thresholds. This should be configurable but many users don’t know
    what to expect so there should be a reasonable default.

I’ve seen latexdiff take forever in past executions and had to give up
and kill it. The document latexdiff struggles with at the moment is a
bilingual document that uses parcolumns to produce a left and right
column.

After letting it run 24 hours it’s still running. So I’m pulling the
plug.

Dear reporter.  Without access to the report-old.tex and report_new.tex
files this bug report is impossible to address. I have not encountered
this behaviour before, not have I seen it reported in other ways.

Actually even better if you can whittle down to the paragraph that
causes the problem.  Probably, it is a single expression on which a
regex tripped.
11-page documents should not take more than 10 seconds or so if there is
a moderate amount of changes. Unless you are processing a whole book, I
would not expect running time of more than a minute.

The described work-around is impossible to implement, unfortunately, as
in pre- and post-processing many small tasks are done in sequence on the
whole document; mostly these are complex regular expression
substitutions, so the hard work is done by perl's RegEx engine, and this
cannot be micro-managed.

Frederik

Dear reporter.  Without access to the report-old.tex and report_new.tex
files this bug report is impossible to address. I have not encountered
this behaviour before, not have I seen it reported in other ways.

Actually even better if you can whittle down to the paragraph that
causes the problem.  Probably, it is a single expression on which a
regex tripped.
11-page documents should not take more than 10 seconds or so if there is
a moderate amount of changes. Unless you are processing a whole book, I
would not expect running time of more than a minute.

The described work-around is impossible to implement, unfortunately, as
in pre- and post-processing many small tasks are done in sequence on the
whole document; mostly these are complex regular expression
substitutions, so the hard work is done by perl's RegEx engine, and this
cannot be micro-managed.

Frederik

I just sent you the documents directly, which will reproduce the
issue. At the moment I would rather not publish them here.

What I will say for anyone else who wants to work on this is that the
document was split into several pieces and latexdiff executed on each
piece, in attempt to isolate the problem. Every piece ran quickly and
correctly terminated. So the defect is perhaps related to a transition
from one piece to another.