anchor.diff:  // TESTRESPONSE[s/]$/],"rewrite_time": $body.$_path, "collector": $body.$_path}], "aggregations": []}]}}/]
   // TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
   // TESTRESPONSE[s/"breakdown": \{...\}/"breakdown": $body.$_path/]
  -<1> The breakdown timings are omitted for simplicity
  -
  -Based on the profile structure, we can see that our `match` query was rewritten by Lucene into a BooleanQuery with two
  -clauses (both holding a TermQuery).  The `type` field displays the Lucene class name, and often aligns with
  -the equivalent name in Elasticsearch.  The `description` field displays the Lucene explanation text for the query, and
  -is made available to help differentiating between parts of your query (e.g. both `message:search` and `message:test`
  -are TermQuery's and would appear identical otherwise.
  -
  -The `time_in_nanos` field shows that this query took ~1.8ms for the entire BooleanQuery to execute.  The recorded time is inclusive
  -of all children.
  -
  -The `breakdown` field will give detailed stats about how the time was spent, we'll look at
  -that in a moment.  Finally, the `children` array lists any sub-queries that may be present.  Because we searched for two
  -values ("search test"), our BooleanQuery holds two children TermQueries.  They have identical information (type, time,
  -breakdown, etc).  Children are allowed to have their own children.
  -
  -====== Timing Breakdown
  -
  -The `breakdown` component lists detailed timing statistics about low-level Lucene execution:
  +<1> The breakdown timings are omitted for simplicity.
  +
  +Based on the profile structure, we can see that our `match` query was rewritten 
  +by Lucene into a BooleanQuery with two clauses (both holding a TermQuery).  The 
  +`type` field displays the Lucene class name, and often aligns with the 
  +equivalent name in Elasticsearch.  The `description` field displays the Lucene 
  +explanation text for the query, and is made available to help differentiating 
  +between parts of your query (e.g. both `message:search` and `message:test` are 
  +TermQuery's and would appear identical otherwise.
  +
  +The `time_in_nanos` field shows that this query took ~1.8ms for the entire 
  +BooleanQuery to execute.  The recorded time is inclusive of all children.
  +
  +The `breakdown` field will give detailed stats about how the time was spent, 
  +we'll look at that in a moment.  Finally, the `children` array lists any 
  +sub-queries that may be present.  Because we searched for two values ("search 
  +test"), our BooleanQuery holds two children TermQueries.  They have identical 
  +information (type, time, breakdown, etc).  Children are allowed to have their 
  +own children.
  +
  +===== Timing Breakdown
  +
  +The `breakdown` component lists detailed timing statistics about low-level 
  +Lucene execution:
   
   [source,console-result]
   --------------------------------------------------
  
positive.code: // TESTRESPONSE[s/]$/]}], "aggregations": []}]}}/]
  // 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:
  
  
negative.code:     means the `collect()` method was called on two different documents.
  
  [[profiling-considerations]]
  ===== Profiling Considerations
  
  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 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.
  
  There are also cases where special Lucene optimizations are disabled, since they 
  are not amenable to profiling. This could cause some queries to report larger 
  relative times than their non-profiled counterparts, but in general should not 
  have a drastic effect compared to other components in the profiled query.
  
  [[profile-limitations]]
  ===== 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 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 other bugs, please report them!
  