Improvement backports from CDT_3 branch (Follow-up to PR #8170)

[lrineau]

Summary of Changes

In the PR #8170, merged for CGAL-6.0, there was several commits that I had to revert, because they broke the testsuite results:

• commit 612d6e3, that modified the function save_binary_file. That was no correct as regards to the C3t3 concept. It is now fixed by commit c10dcf7 from this PR.
• commit 1ca6c17, that optimized the efficiency of Polyline_constraint_hierarchy_2 using an unordered map, instead of a std::map. The issue was that is broke the determinism of Mesh_2. See Improvement backports from CDT_3 branch (Follow-up to PR #8170) #8273 (comment).
• commit ac47f30, that introduced an experimental tuple protocol for CGAL::Segment_3, for some CGAL kernels.
• commit df28ddc, that fixed a CMake warning about VTK-9.x. Now fixed by another PR (Update CMakeLists.txt for recent VTK to fix CMake Warning #8279).

This pull-request reintroduces those features, for CGAL-6.1.

Release Management

• Affected package(s):
• License and copyright ownership: maintenance by GeometryFactory

[lrineau]

Order of the sequence of values from the range CGAL::Constrained_triangulation_plus_2<Tr>::subconstraints()

@janetournois @afabri

• The patch 93fd966 makes the range CGAL::Constrained_triangulation_plus_2<Tr>::subconstraints() non-deterministic: instead of a std::map with a custom compare functor, now the sub-constraints are in an unordered map, for efficiency reasons. Note that the range was never documented as sorted or deterministic.
• As my patch had broken a test from Mesh_2 (the test test_meshing), I had to fix that non-determinism. That was complicated to fix directly in Constrained_triangulation_plus_2 or Constrained_triangulation_plus_2. Instead, I have chosen to fix the only place in CGAL where the order of that range mattered, in Mesh_2/include/CGAL/Mesh_2/Refine_edges.h. See the commit 82b5359.

Is that correct? That is a sort of breaking change, but the ordering of Ctp_2::constraints() was never documented.

[lrineau]

Jane (IRL) suggested that:

• it is documented that there is a breaking change
• and add a Tag to Constrained_triangulation_plus_2 to allow users to fallback to the previous behavior.

[afabri]

Any idea how big the gain in efficiency is @lrineau ?

[sloriot]

In order to avoid ping-pong changes, I suggest to have CGAL::unordered_map and to use it everywhere (at least for default hashable items).

[lrineau]

Speedups

@afabri:

Any idea how big the gain in efficiency is @lrineau ?

One the data set "Thingi #101881", I have run the experimental CDT_3 code, with compilation flags -O3 -DCGAL_NDEBUG. The timings of the step "conforming of facets borders" vary a lot:

with...	time	factor
std::map	4110 ms	1.00
std::unordered_map	3623 ms	0.88
boost::unordered_flat_map	2897 ms	0.70

I have repeated multiple time each of the three runs. The variance of the timings between each run is less than 5%, and the difference between the three implementations is about 15%.

And the code the "CDT_3 conforming" does a lot more than just handling the CGAL::Constrained_triangulation_plus_2 data-structure. The speedups are significant, in my opinion.

Code

@sloriot:

I suggest to have CGAL::unordered_map

Indeed. I have a patch. I will push it...

[afabri]

We had several times users where we worked hard to make algorithms deterministic for reproductibility. So this is maybe more important than speed. Also I find it more natural that subconstraints are ordered along the constraint.

[afabri]

I just realize that subconstraints are not the subconstraints of a constraint, but all subconstraints in the constrained triangulation. Instead iterating over the Xmap, why don't we iterate over the vertices of the constraints, as a subconstraint is just a pair of consecutive vertices on a constraint?

[lrineau]

CGAL::unordered_map

I have pushed the commit 5526857. The results of the testsuites of Triangulation_2, Mesh_2, and Polyline_simplification_2 are PASSED on my machine (with Boost.Unordered available).