Faster binary subdivision map generation

[GeorgeR227]

Main speedup is a result of how edge vertices are accessed. Before the pattern was s[:∂v0][i] and is now s[i, :∂v0]. This method also no longer directly edits a sparse matrix and instead creates it from row, col and value arrays.

Benchmarks are below. Further improvements could be gained by improving the binary_subdivision function.

8 by 8
Old method
  0.000775 seconds (7.50 k allocations: 1.420 MiB)
New method
  0.000255 seconds (4.18 k allocations: 523.734 KiB)

16 by 16
Old method
  0.004468 seconds (31.81 k allocations: 12.524 MiB)
New method
  0.000828 seconds (15.68 k allocations: 1.895 MiB)

32 by 32
Old method
  0.126676 seconds (132.57 k allocations: 161.549 MiB, 50.90% gc time)
New method
  0.003413 seconds (61.26 k allocations: 7.751 MiB)

64 by 64
Old method
  0.947636 seconds (537.05 k allocations: 2.339 GiB, 42.35% gc time)
New method
  0.015285 seconds (242.99 k allocations: 28.643 MiB, 20.52% gc time)

128 by 128
Old method
  9.914007 seconds (2.15 M allocations: 36.545 GiB, 20.43% gc time)
New method
  0.079384 seconds (968.90 k allocations: 115.399 MiB, 29.55% gc time)

[lukem12345]

Profview says that remaining bottlenecks are due to triangle gluing in the binary subdivision function. It doesn’t seem like any further performance improvements are necessary for the mesh sizes we are currently interested in, and triangle gluing is a fairly common idiom for writing high level code in this library, so we are good to merge.

The binary subdivision function could be sped up by some bookkeeping with edge indices if necessary.