[Gmsh] "Re: GMSH parsing is very slow"

[Al Sc]

Dear Sir or Madam,

some more details on the previously-reported case of extremely slow parsing
of a gmsh file:
The file contains 34795 points -- of which 23041 points are "Point In
Volume" (e.g. embedded_vertices of a GRegion?). Moreover, it contains 4998
"Plane Surface"s and one single "Volume". Almost all plane surfaces are
triangles and quads -- except for <10 facets, which each have a very high
vertex count (typ. 7000).

I found out that if I remove all "Point In Volume" objects, then the
parsing takes only 20 seconds. However, if all the "Point In Volume"
objects are not removed, parsing takes around 3000 seconds. This led me to
the hypothesis that there is some huge inefficiency with parsing gmsh files
with "Point In Volume" (probably quadratic run time in N(PointInVolume)??).

Furthermore, I analyzed the runs using "perf" (linux utility).
Run 1 (about 3000 seconds):
  $ time perf record ./gmsh-3.0.6-Linux64/bin/gmsh -1 input_orig.geo
Run 2 (about 20 seconds):
  $ time perf record ./gmsh-3.0.6-Linux64/bin/gmsh -1
input_no_point_in_volume.geo
In Run 1, "perf report" yields the following top-scoring functions:
  11.57%  gmsh     gmsh                 [.] GModel::getEdgeByTag
   7.73%  gmsh     gmsh                 [.] GEO_Internals::synchronize
   6.80%  gmsh     libc-2.12.so         [.] _int_free
   6.31%  gmsh     gmsh                 [.] GModel::getVertexByTag
   4.91%  gmsh     libc-2.12.so         [.] malloc
   4.53%  gmsh     gmsh                 [.] InterpolateCurve
   4.40%  gmsh     libstdc++.so.6.0.22  [.] std::_Rb_tree_increment
   3.88%  gmsh     libc-2.12.so         [.] memcpy
   3.69%  gmsh     gmsh                 [.] List_Nbr
   3.35%  gmsh     libc-2.12.so         [.] _int_malloc
   3.24%  gmsh     gmsh                 [.] GEntity::GEntity
   3.13%  gmsh     gmsh                 [.] avl_lookup
   2.63%  gmsh     gmsh                 [.] gmshFace::resetNativePtr
   2.53%  gmsh     gmsh                 [.] GEdge::addFace
   2.52%  gmsh     gmsh                 [.] CompareVertex
   1.97%  gmsh     gmsh                 [.] std::_List_base<GEdge*,
std::allocator<GEdge*>
   1.88%  gmsh     gmsh                 [.] GModel::getFaceByTag
   1.76%  gmsh     gmsh                 [.] Tree_Action
   1.74%  gmsh     gmsh                 [.] gmshEdge::degenerate
   1.63%  gmsh     gmsh                 [.] CompareCurve
   1.53%  gmsh     gmsh                 [.] std::_List_base<int,
std::allocator<int> >::_M
   1.38%  gmsh     gmsh                 [.] GModel::deletePhysicalGroups
   1.23%  gmsh     gmsh                 [.] std::_List_base<GEdgeSigned,
std::allocator<GE
   1.10%  gmsh     gmsh                 [.] GVertex::addEdge
   0.85%  gmsh     gmsh                 [.] List_Read
   0.75%  gmsh     gmsh                 [.] GEdge::getBeginVertex
   0.73%  gmsh     gmsh                 [.] GFace::computeMeanPlane
   0.73%  gmsh     libc-2.12.so         [.] free
   0.67%  gmsh     gmsh                 [.] CTX::instance
   0.65%  gmsh     gmsh                 [.] gmshEdge::resetMeshAttributes

This suggests that maybe GModel::getEdgeByTag is eventually called a
quadratic number of times in the number of PointInVolume-objects -- and
this causes the drastic slow-down.

Could you please investigate this? Thanks a lot!
(As already mentioned, this issue also occurs with gmsh-4.x.x)

Best regards
A. S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://onelab.info/pipermail/gmsh/attachments/20190131/109422a0/attachment.html>