perf: iterate through directed weighted adjacency matrix in storage order

[szhorvat]

Before going further with these sorts of changes, I want to make sure that we are in agreement. The idea is to iterate through (bi)adjacency matrices in storage order for the sake of better performance.

We never formally guaranteed a certain edge ordering here, but neither did we spell out that we don't. Thus some people may have been relying on it. The best time to make this change is therefore 1.0.

Another argument for not guaranteeing an edge order is that those matrix -> graph conversions which do access both $A_{ij}$ and $A_{ji}$ at the same time could be sped up in the future by a similar blocking technique to what was used in igraph_matrix_transpose(). Block sizes should be tunable, and would affect the edge ordering.

If there is a serious concern about the non-stable edge ordering produced by these functions, I suggest adding a new function that canonicalizes the edge order in-place. People who need to rely on the edge order can call this function explicitly. Note that some level of consistency is already achievable using the order parameter of igraph_es_all().

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.63%. Comparing base (ae7dfc3) to head (5bf2825).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #2591   +/-   ##
========================================
  Coverage    84.63%   84.63%           
========================================
  Files          376      376           
  Lines        60775    60786   +11     
  Branches     11884    11887    +3     
========================================
+ Hits         51434    51445   +11     
  Misses        9341     9341           

Files	Coverage Δ
src/constructors/adjacency.c	98.72% <100.00%> (+0.02%)	⬆️
src/misc/bipartite.c	91.81% <100.00%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ae7dfc3...5bf2825. Read the comment docs.

[ntamas]

Looks good to me in general and I agree with spelling out that we are not guaranteeing any specific edge ordering.

[szhorvat]

This is it for now, I won't implement cache blocking for the undirected case yet.

For the rest, the performance gains are significant.