Just thought this may be interesting.
Though the results are for "eyeballing" at best -- see the video linked in Jonas' recent mail:
https://lists.freepascal.org/pipermail/fpc-devel/2022-January/044336.html

I run my FpDebug test case with 3.2.3 and 3.3.1 (both early Dec)

The test runs about 15 secs (evaluating approx 70k watches). The test was done with a modified FpDebug for single threaded execution (threaded results are similar, but have more variance)

Tests done with

FPC 3.2.3 -O2  :  14.1 - 14.3 sec
FPC 3.3.1 -O2  :  13.3 - 13.5 sec

FPC 3.2.3 -O-1 -gw3  :  15.0 - 15.2 sec
FPC 3.3.1 -O-1 -gw3   :  14.3 - 14.5 sec

So on my PC, with this particular compilation setting the speedup (intentional plus side-effects) is 4 to 5 percent.

I7- 8600K
Win 64 bit

Can't do 3.2.2 or 3.2.0 as they have that bug, that crashes fpdebug. https://gitlab.com/freepascal.org/fpc/source/-/commit/e9d318e7e2f772bf455a92461cd5c229e69858d8

What about -O3?

Ups, the above was misleading.

The O1/O2 was only compiler and rtl.

FpDebug, the testcase, and LazUtils where build in all cases with -O4.

Running with FPC/rtl on  -O4

FPC 3.2.3 -O4 : 13.8 - 14.0 sec
FPC 3.3.1 -O4 : 13.0 - 13.2 sec

Compiling the TEST (and fpdebug/lazutils) with -O3 instead.

TEST -O3 / FPC 3.2.3 -O2 : 13.9 - 14.0 sec
TEST -O3 / FPC 3.3.1 -O2 : 13.1 - 13.2 sec

TEST -O3 / FPC 3.2.3 -O-1 -gw3 : 14.9 - 15.2 sec
TEST -O3 / FPC 3.3.1 -O-1 -gw3 : 14.1 - 14.3 sec

Interesting, the last one "TEST -O3 FPC -O2" is a bit faster, than the "test -O4 / FPC -O2" with the same fpc in the original post (very first test in the orig mail).
So either there are side-effects, or something is overdone....

---------------------------
I'll see to it, that I commit the testcase with the option to use "none threading".
So it can be run by others too.
Maybe (if interest exists, and I find a few minutes) add a benchmark wrapper.

I have not (yet) profiled the testcase.
The time would go into
- loading the exe (it is already pre-compiled), and start the exe in the debugger, run to breakpoint
  (the testcase, contains an fpdebug debugger, that loads and debugs a real exe)
- pre-parsing the debug info
- looking up info for each watch
- formatting the watch as string
- in the test, compare or regex-match the string

The first (actually first 2 steps) are not dependent on the number of watches. The majority of the time goes (should go) into the last 3 steps. I could imagine, but as I said not yet profiled, that string processing takes it noticeable share.
If, so that might be part of why the rtl optimization level has such