anchor.diff:  to execute the post_filter (and in turn wraps the normal scoring SimpleCollector), a BucketCollector to run
   all scoped aggregations.  In the MatchAll search, there is a single GlobalAggregator to run the global aggregation.
   
  -=== Performance Notes
  -
  -Like any profiler, the Profile API introduce a non-negligible overhead to query execution.  The act of instrumenting
  -low-level method calls such as `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.
  -
  -=== Limitations
  -
  -- Profiling statistics are currently not available for suggestions, highlighting, `dfs_query_then_fetch`
  -- Detailed breakdown for aggregations is not currently available past the high-level overview provided
  -from the Collectors
  -- 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!
  -
  -=== Understanding MultiTermQuery output
  +==== Understanding MultiTermQuery output
   
   A special note needs to be made about the `MultiTermQuery` class of queries.  This includes wildcards, regex and fuzzy
   queries.  These queries emit very verbose responses, and are not overly structured.
  
positive.code: ignore it's children if you find the details too tricky to interpret.
  
  Hopefully this will be fixed in future iterations, but it is a tricky problem to solve and still in-progress :)
  
negative.code: experimental[]
  
  The Profile API provides detailed timing information about the execution of individual components
  in a search request.  It gives the user insight into how search requests are executed at a low level so that
  the user can understand why certain requests are slow, and take steps to improve them.
  
  The output from the Profile API is *very* verbose, especially for complicated requests executed across
  many shards. Pretty-printing the response is recommended to help understand the output
  
  [float]
  === Usage
  