Merge pull request github#8252 from github/RasmusWL/debugging-dataflow-improvements

Docs: Mention `hasPartialFlowRev` and performance problem

Author: RasmusWL

docs/codeql/writing-codeql-queries/debugging-data-flow-queries-using-partial-flow.rst

@@ -78,6 +78,8 @@ To avoid these problems, a data-flow ``Configuration`` comes with a mechanism fo
        */
       final predicate hasPartialFlow(PartialPathNode source, PartialPathNode node, int dist) {
 
+There is also a ``Configuration.hasPartialFlowRev`` for exploring flow backwards from a sink.
+
 As noted in the documentation for ``hasPartialFlow`` (for example, in the 
 `CodeQL for Java documentation <https://codeql.github.com/codeql-standard-libraries/java/semmle/code/java/dataflow/internal/DataFlowImpl2.qll/predicate.DataFlowImpl2$Configuration$hasPartialFlow.3.html>`__) you must first enable this by adding an override of ``explorationLimit``. For example:
 
@@ -87,6 +89,8 @@ As noted in the documentation for ``hasPartialFlow`` (for example, in the
 
 This defines the exploration radius within which ``hasPartialFlow`` returns results.
 
+To get good performance when using ``hasPartialFlow`` it is important to ensure the ``isSink`` predicate of the configuration has no results. Likewise, when using ``hasPartialFlowRev`` the ``isSource`` predicate of the configuration should have no results.
+
 It is also useful to focus on a single source at a time as the starting point for the flow exploration. This is most easily done by adding a temporary restriction in the ``isSource`` predicate.
 
 To do quick evaluations of partial flow it is often easiest to add a predicate to the query that is solely intended for quick evaluation (right-click the predicate name and choose "CodeQL: Quick Evaluation"). A good starting point is something like:
@@ -113,4 +117,4 @@ Further reading
 ----------------
 
 - :ref:`About data flow analysis <about-data-flow-analysis>`
-- :ref:`Creating path queries <creating-path-queries>`
+- :ref:`Creating path queries <creating-path-queries>`