anchor.diff:  }
   ----
   
  -The `size()` of the returned `List` is the `partCount`, so the number of partitions.
  -This can be decided dynamically, for example based on the size of the non-partitioned solution.
  +The `size()` of the returned `List` is the `partCount` (the number of partitions).
  +This can be decided dynamically, for example, based on the size of the non-partitioned solution.
   The `partCount` is unrelated to the `runnablePartThreadLimit`.
   
   For example:
  
positive.code: * `UNLIMITED`: Allow Planner to occupy all CPU cores, do not avoid hogging.
  Useful if a no hogging CPU policy is configured on the OS level.
  * `AUTO` (default): Let Planner decide how many CPU cores to occupy. This formula is based on experience.
  It doesn't hog all CPU cores on a multi-core machine.
  * Static number: The number of CPU cores to consume. For example:
  +
  [source,xml,options="nowrap"]
  
negative.code: ----
  
  The `threadFactoryClass` allows to plug in a custom `ThreadFactory` for environments
  where arbitrary thread creation should be avoided, such as most application servers, Android, or Google App Engine.
  
  The `runnablePartThreadLimit` allows limiting CPU usage, see below.
  
  Just like a `<solver>` element, the `<partitionedSearch>` element can contain one or more <<solverPhase,phases>>.
  Each of those phases will be run on each partition.
  
  A common configuration is to first run a Partitioned Search phase
  (which includes a Construction Heuristic and a Local Search)
  followed by a non-partitioned Local Search phase:
  
  [source,xml,options="nowrap"]
  ----
  