Can you send a test file?
I tried this, i.e. adding 1000 embedded points in a volume, and it is quite
fast (< 2 seconds):
SetFactory("OpenCASCADE");
Box(1) = {0,0,0, 1,1,1};
For i In {1:1000}
Point(100+i) = {0.25 + 5e-4*i, 0.1,0.1};
Point{100+i} In Volume{1};
EndFor
Maybe you modify the model after each insertion of an embedded point, which
would force a rebuild of the topological model?
Christophe
> On 31 Jan 2019, at 13:04, Al Sc <[email protected]> wrote:
>
> 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.
> _______________________________________________
> gmsh mailing list
> [email protected]
> http://onelab.info/mailman/listinfo/gmsh
—
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine
_______________________________________________
gmsh mailing list
[email protected]
http://onelab.info/mailman/listinfo/gmsh
