Add incident_cells_3(Vertex_handle, std::vector<Cell_handle>)
This function avoids the construction of two additional std::vectors.
The performance gain is between 30% (g++) and 50% (VC++)
for points on surfaces as well as for points filling space.
We at the same time change the implementation of the function
incident_cells(Vertex_handle, OutputIterator).
In order to save one additional std::vector,
the cells are reported in bfs and not in dfs order
I remade a benchmark and finally when using boost::thread_specific_ptr,
using a std::vector is faster than the dedicated vector-class I previously
use.
I also retry using a tuple instead of a dedicated class to store variables
useful for the emulated recursion but tuple is (on my machine) slower.
benchmark results are the following (points are randomly taken in a sphere,
time is in seconds and is the mean of 10 idendical runs)
nb points | 1000 100000 100000 1000000 10000000
-----------------------------------------------------------------------------
trunk version | 0.0088 0.0928 0.9865 10.216 102.99
with vector | 0.0096 0.0900 0.9817 10.075 102.24
with vector and tuple | 0.0100 0.0948 0.9981 10.219 104.58
recursive version | 0.0080 0.0936 0.9732 10.141 102.33
--create an internally used vector that can reserve its size when constructed
--create an internally used class to store information required to emulated the call stack
--the stack used to emulate the call stack is a static thread-safe vector of the function (thus a memory overhead)
These choices have been made so that the running time of the triangulation is still the same.
by namespace CGAL { and } //namespace CGAL. in all .h and .cpp files
in a directory.
Apply it to all packages in the trunk
Remove macro definition from the config.h file.
r19107 | afabri | 2003-10-17 10:49:19 +0200 (Ven 17 oct 2003) | 2 lignes
Added const& for gaining performance
which was justified at the time by the fact that on VC++, handles encapsulated iterators.
See Andreas' e-mail:
> I just had a look at the code. The problem is that it calls
> incident_cells, which is implemented recursively, and for a
> vertex with many incident cells, as in your case the infinite
> vertex, the stack is full.
>
> We have to put it on our todo list.
I did it for 3D only because the degenerate 2D case should be
handled by the circulator anyway.
I did not add the test which explodes the call stack (in case we plug
the recursive version): too slow for a testsuite. But incident_...
methods are used everywhere in the code anyway.
- all the code is factored around visit_incident_cells.
- incident_edges has been added
- finite versions of all incident_*(vertex) have been added
thanks to a Filter template parameter
mode
- fixed only if dimension()==3. If dimension()<3, tds.print_cells() should
be corrected. The handling of the dimension is ugly (copy-pasting). I
prefere not to fix that code.
Note 1: Test suite is ok.
Note 2: binary i/o operators are tested in Mesh_3
Jane Tournois
Laurent Rineau
Sébastien Loriot
Andreas Fabri
Sylvain Pion
Monique Teillaud
Camille Wormser
Nico Kruithof