mention some RTS options in profiling.md (#3713)

Documentation only.

docs/profiling.md

@@ -90,14 +90,34 @@ The profiling information can also be useful when hunting for other bugs, such a
 |---|---|---|---|
 | `-xc` | `-prof -fprof-auto` | Causes the runtime to print out the current cost-centre stack whenever an exception is raised. Useful for debugging the location of exceptions, such as `Prelude.head: empty list` error. | stderr |
 
-
 ## Costs and disadvantages of profiling
 
 There are two main issues with profiling:
 
 1) Profiling adds an overhead to the overall runtime, so it is only useful if we want to measure the relative runtime of different components of our programs
 2) The addition of cost centers introduced by `-fprof-auto` (`profiling-detail: all-functions`)/`-fprof-auto-top`/`-fprof-auto-exported` can impede certain optimizations such as fusion, which can skew the profile, since we are now profiling code which would otherwise have been optimized, so the % of time spent in the code region will not reflect the un-profiled runtime. There is a potential workaround to this issue in [GHC 9.2](https://discourse.haskell.org/t/profiling-using-late-cost-centres-after-optimization/4664) with a new [`-fprof-late-ccs` flag in GHC 9.4.1](https://ghc.gitlab.haskell.org/ghc/doc/users_guide/profiling.html) which inserts top-level const centers at a late stage of the optimization pipeline
 
+### Things to try and prepare before profiling
+
+As a profiling build is significantly slower than a regular one, more
+light-weight methods with a regular build can already provide enough
+leads to locate an issue that can then be found by code inspection.
+
+* It is always helpful to isolate a single operation that exhibits the
+  problem at hand. This can be a rewrite step or an expected
+  simplification. One can use either the RPC interface or a custom
+  claim `runLemma(expression) => doneLemma(expected-simplification)`
+  (see `evm-semantics` for examples).
+* Using `--log-entries <selection-of-debug-log-entries>`, one can
+  observe where the system is spending time during execution of a
+  request, and most of the time whether and why rules won't apply.
+* Running the program with the `+RTS` option `-Sstderr` (prints GC
+  statistics after every GC) in combination with the `--log-entries`
+  will allow for locating memory-hungry steps in the processing
+  pipeline.
+* When analysing memory issues, it is also helpful to limit the heap
+  size using `+RTS` option `-M <size>`, e.g., `+RTS -M15G -Sstderr`.
+
 
 ## Additional resources