ENH: sparse: speedup LIL matrix slicing

[pv]

The current implementation for slicing LIL matrices is very pessimal. Replace it with a more optimal implementation.

Gives a factor of ~1/density speedup:

In []: A = rand(3000, 3000, density=1e-3, format="lil")

# Before (9ccc68475)
In [4]: %timeit A[::2,::-2]
10 loops, best of 3: 87.5 ms per loop

# After (d47e27b0)
In [4]: %timeit A[::2,::-2]
1000 loops, best of 3: 603 µs per loop

Gives speedups also for smaller slices:

# Before
In [5]: %timeit A[3,:]
1000 loops, best of 3: 213 µs per loop
In [6]: %timeit A[:,3]
1000 loops, best of 3: 901 µs per loop
In [7]: %timeit A[1:5,1:5]
10000 loops, best of 3: 83.3 µs per loop

# After
In [5]: %timeit A[3,:]
10000 loops, best of 3: 38.8 µs per loop
In [6]: %timeit A[:,3]
1000 loops, best of 3: 702 µs per loop
In [7]: %timeit A[1:5,1:5]
10000 loops, best of 3: 40.3 µs per loop

(Column slices in LIL are still problematic, but that's due to the matrix format.)

EDIT updated benchmarks

[pv]

TBH, the LIL/DOK matrices should be reimplemented e.g. in Cython, with appropriate low-level data storage.

[coveralls]

Coverage remained the same when pulling 63988b9 on pv:lil-speed into 2df405a on scipy:master.

[coveralls]

Coverage remained the same when pulling 77929e5 on pv:lil-speed into 2df405a on scipy:master.

[rgommers]

Guess this can be closed?

[pv]

No, this is a different optimization.
Probably needs re-benchmarking and reimplementation in Cython.

[pv]

Rebased and cythonized.

[coveralls]

Changes Unknown when pulling d47e27b on pv:lil-speed into * on scipy:master*.

[jnothman]

Is there a reason this is inlined rather than using _check_row_bounds?

[jnothman]

Otherwise, this LGTM

[rgommers]

This needs only a rebase and a very minor tweak it looks like. Time to get it in?

[perimosocordiae]

Rebased in #5789, closing.

[larsmans]

Reopening so that the status of this will be "merged" when I merge #5789.