Performance Improvements and New Algorithms

While working on #51 I realized that there is quite a bit of memory/performance tradeoff, similar to what happens in Meshing.jl. In Meshing.jl we have three algorithms with different performance and output characteristics to give the user some control based on requirements. I realize in Contour there is a similar balance, but no analogous control.

In Meshing.jl we have MarchingCubes which traverses the array and gives triangles without connectivity. There is also MarchingTetrahedra which gives connectivity but is ~4x slower.

My proposal is to implement a similar system for specifying an algorithm and output to contour.

• Original API and Algorithm remains unchanged.
• Add a BigMemoryConnected (name TBD) algorithm like #51
• Add a EdgeSoupUnconnected (name TBD) algorithm which just generated edge pairs, without polygon loops

The benefit of BigMemoryConnected is that it is faster than the default and will still give the same output to the algorithm in place now. Downsides are that the memory requirement is large ~1/8 the z grid size.

EdgeSoupUnconnected should have almost not allocations outside the allocation of the output, and will be the fastest. However it will not generate polygons/polylines, but rather edge pairs. This means the output size will be larger, but the actual processing done in Contour should be orders of magnitude faster, and overall memory should be much smaller.

Bonus round

Direct function sampling. In this case, contours can be generated without allocating a z-grid. For simple analytic functions, this can yield overall good performance improvements.

Start by reading issue #51 and the existing Contour API and algorithm behavior referenced here. Compare the proposed MarchingCubes, MarchingTetrahedra, BigMemoryConnected, and EdgeSoupUnconnected approaches in Meshing.jl. Done should include a settled algorithm/output API, preserved behavior for the original API, and validated performance and memory characteristics.