anchor.diff:  // TESTRESPONSE[s/"next_doc": 53876/"next_doc": $body.profile.shards.0.searches.0.query.0.breakdown.next_doc/]
   
   Timings are listed in wall-clock nanoseconds and are not normalized at all.  All caveats about the overall
  -`"time"` apply here.  The intention of the breakdown is to give you a feel for A) what machinery in Lucene is
  +`time` apply here.  The intention of the breakdown is to give you a feel for A) what machinery in Lucene is
   actually eating time, and B) the magnitude of differences in times between the various components.  Like the overall time,
   the breakdown is inclusive of all children times.
   
  
positive.code: From the profile structure we can see our `property_type` terms aggregation which is internally represented by the
  `GlobalOrdinalsStringTermsAggregator` class and the sub aggregator `avg_price` which is internally represented by the `AvgAggregator` class. The `type` field displays the class used internally to represent the aggregation. The `description` field displays the name of the aggregation.
  
  The `"time"` field shows that it took ~4 seconds for the entire aggregation 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-aggregations that may be present.  Because we have an `avg_price` aggregation as a sub-aggregation to the `property_type` aggregation we see it listed as a child of the `property_type` aggregation.  the two aggregation outputs 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,js]
  --------------------------------------------------
  
negative.code: <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` field shows that this query took ~1.8ms for the entire BooleanQuery to execute.  The recorded time is inclusive
  of all children.
  
  The `time_in nanos` field shows the timing information in an exact, machine readable format in nanoseconds.
  
  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.
  
  NOTE: The `time` field is only intended for human consumption. If you need exact timing values use `time_in nanos`. The `time`
  field is currently printed by default, but this will change with the next major version (6.0.0) where `time_in_nanos` will be
  printed by default.
  
  
  ===== Timing Breakdown
  
  The `breakdown` component lists detailed timing statistics about low-level Lucene execution:
  
  [source,js]
  --------------------------------------------------
  