improving shortest path all pairs through BFS computations

[ncohen]

After taking a look at the SparseGraph? backend, it looks like some time is actually spent obtaining the list of neighbors. This patch caches so that the out_neighbors method does not have to be called so often.

[ncohen]

Before

sage: g = graphs.Grid2dGraph(60,60)
sage: %time d = g.shortest_path_all_pairs()
CPU times: user 14.52 s, sys: 0.51 s, total: 15.03 s
Wall time: 15.03 s
sage: g = graphs.Grid2dGraph(30,30)
sage: %timeit d = g.shortest_path_all_pairs()
5 loops, best of 3: 752 ms per loop
sage: g = graphs.PetersenGraph()
sage: %timeit d = g.shortest_path_all_pairs()
625 loops, best of 3: 73.5 µs per loop

After

sage: g = graphs.Grid2dGraph(60,60)
sage: %time d = g.shortest_path_all_pairs()
CPU times: user 10.70 s, sys: 0.53 s, total: 11.23 s
Wall time: 11.24 s
sage: g = graphs.Grid2dGraph(30,30)
sage: %timeit d = g.shortest_path_all_pairs()
5 loops, best of 3: 549 ms per loop
sage: g = graphs.PetersenGraph()
sage: %timeit d = g.shortest_path_all_pairs()
625 loops, best of 3: 53.4 µs per loop

[ncohen]

I had set this patch to "needs review", as I was wondering why Cython was apparently slower than a C code I had written independently. Turns out the different lies in how the vertices of the 2d grid (which is the graph on which I was testing the performances) were labelled.

In the C code, they were labelled from left to right, then from top to bottom, why Sage's numbering is much more random, hence different performances in practice.

Hail Cython ;-)

Nathann

[lsampaio]

I reviwed the patch and it seens to be working well!