anchor.diff:  ==== Limitations
   
   - Profiling currently does not measure the search fetch phase nor the network overhead
  -- Profiling also does not account for time spent in the queue, merging shard responses on the coordinating node or
  -additional work like e.g. building global ordinals (an internal data structure used to speed up search)
  +- Profiling also does not account for time spent in the queue, merging shard responses on the coordinating node, or
  +additional work such as building global ordinals (an internal data structure used to speed up search)
   - Profiling statistics are currently not available for suggestions, highlighting, `dfs_query_then_fetch`
   - Profiling of the reduce phase of aggregation is currently not available
   - The Profiler is still highly experimental. The Profiler is instrumenting parts of Lucene that were
   never designed to be exposed in this manner, and so all results should be viewed as a best effort to provide detailed
  -diagnostics.  We hope to improve this over time. If you find obviously wrong numbers, strange query structures or
  +diagnostics.  We hope to improve this over time. If you find obviously wrong numbers, strange query structures, or
   other bugs, please report them!
  
positive.code: // TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
  
  We see a single collector named `SimpleTopScoreDocCollector` wrapped into `CancellableCollector`. `SimpleTopScoreDocCollector` is the default "scoring and sorting"
  `Collector` used by Elasticsearch.  The `reason` field attempts to give a plain english description of the class name.  The
  `time_in_nanos` is similar to the time in the Query tree: a wall-clock time inclusive of all children.  Similarly, `children` lists
  all sub-collectors. The `CancellableCollector` that wraps `SimpleTopScoreDocCollector` is used by Elasticsearch to detect if the current
  search was cancelled and stop collecting documents as soon as it occurs.
  
  It should be noted that Collector times are **independent** from the Query times.  They are calculated, combined
  and normalized independently!  Due to the nature of Lucene's execution, it is impossible to "merge" the times
  from the Collectors into the Query section, so they are displayed in separate portions.
  
  For reference, the various collector reason's are:
  
  [horizontal]
  `search_sorted`::
  
negative.code: // TESTRESPONSE[s/\.\.\.//]
  // TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
  // TESTRESPONSE[s/"id": "\[P6-vulHtQRWuD4YnubWb7A\]\[test\]\[0\]"/"id": $body.profile.shards.0.id/]
  <1> The `"aggregations"` portion has been omitted because it will be covered in the next section
  
  As you can see, the output is significantly more verbose than before.  All the major portions of the query are
  represented:
  
  1. The first `TermQuery` (user:test) represents the main `term` query
  