I'm not sure this is the right place to ask, but I'm very frustrated by this issue, and I don't know of any other place to ask. I am not a professional programmer. Neither have I any education in computer science. Please forgive my inaccuracies in explaining the issue. Please excuse my terrible use of the English language as well. As a hobby, I wrote a finite volume library in C++. This library consumes meshes generated by Gmsh and performs some calculations. The library originally read the gmsh files, but the gmsh developers decided to change frequently the format of their files, providing C++/C/python/julia APIs to read their files, so that changes of their file formats are transparent to the users. The API is relatively simple ( https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/api/gmsh.h) and can be compiled as a shared or static library. After changing my library to use their API, I noticed a significant slowdown in my programs. I thought of filing an issue against gmsh. However, while I was investigating the issue to prepare my report, I realized that the issue was caused by a single line of code in gmsh: https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/Geo/GFace.cpp#L143, which is simply calling delete to free memory of a set of polymorphic objects (quadrangles in my testcase). My program workflow is: 1. Reading the gmsh file 2. Finishing using the gmsh API, thus calling the abovementioned line of code. 3. Doing the actual calculation, which may take hours, depending on the case. 1. and 2 take negligible time. However, they slow down the calculation by about 30%, compared with the situation in which I wasn’t using the API. Furthermore, if I comment out that line, thus leaking memory, and recompile libgmsh, I recover back the original performance. Why does deleting temporary objects in a shared library affect the performance of an unrelated part of the program? Does that make sense? I might provide a testcase, but it would be somewhat large and dependent of libgmsh.
