anchor.diff:  
   3. Large graphs requiring an approach with `HadoopGraph` and `SparkGraphComputer` to yield results in a reasonable time.
   
  -
   These regimes are discussed separately using the following graph with three weakly connected components:
   
   image:connected-components.png[width=600]
  
positive.code: pure depth-first-search or breadth-first-search implementations, connected-component algotithms should scale
  as [.big]##O##(V+E). For the traversals in the figure above this is almost the case.
  
  
  [[cc-scale-ratio]]
  .Run times for finding connected components in a randomly generated graph with 10 components, each consisting of 6400 vertices
  image::cc-scale-ratio.png[width=600]
  
negative.code: 
  Scalability of the the `connectedComponent()`-step with `SparkGraphComputer` is high, but note that:
  
  * The graph should fit in the memory of the Spark cluster to allow the VertexProgram to run its cycles without spilling
  intermediate results to disk and loosing most of the gains from the distributed processing.
  * As discussed for small graphs, the BSP algorithm does not play well with graphs having a large shortest path between
  any pair of vertices. Overcoming this limitation is still a
  link:http://www.vldb.org/pvldb/vol7/p1821-yan.pdf[subject of academic research].