anchor.diff:  ==== Performance Notes
   
   Like any profiler, the Profile API introduces a non-negligible overhead to search execution.  The act of instrumenting
  -low-level method calls such as `collect`, `advance` and `next_doc` can be fairly expensive, since these methods are called
  +low-level method calls such as `collect`, `advance`, and `next_doc` can be fairly expensive, since these methods are called
   in tight loops.  Therefore, profiling should not be enabled in production settings by default, and should not
   be compared against non-profiled query times.  Profiling is just a diagnostic tool.
   
  
positive.code: `search_multi`::
  
      A collector that wraps several other collectors.  This is seen when combinations of search, aggregations,
      global aggs and post_filters are combined in a single search.
  
  `search_timeout`::
  
  
negative.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 reasons are:
  
  [horizontal]
  `search_sorted`::
  