This was likely not the right place to ask, so I hope the experts don't mind my trying to answer: That symptom only makes sense if your long computation does a very large amount of allocating and freeing memory. Even then, it implies some flaw in library routines that handle allocating and freeing memory. Very long ago, working on a large commercial project, I did find such flaws in those routines, where certain patterns of allocating memory caused pathological slowdown in the then standard GNU library routines for managing the pool of freed memory. At that time, I reviewed available online alternatives, and then wrote my own. Years later, I noticed the then current GNU version no longer had the problem and I dropped my own. Longing for an alternate version of the function that manages the pool of freed memory might be a practical choice. But first you should review your own code for the places it does a large number of allocations and deletions of objects. Regardless of the flaw currently making that much worse, that is likely an underlying performance flaw in your own code. Changing your code to need fewer allocations an deletions might gain back more that the 30% you lost. Another alternative it to switch some of your key data structures to use private memory pools. For some data structures, that can have a dramatic improvement in performance. It is a bit tricky at first to follow one of the many online examples of using a custom memory pool, but you may find it interesting. -----Original Message----- From: Alberto Gcchelp via Gcc-help <gcc-help@xxxxxxxxxxx> To: gcc-help@xxxxxxxxxxx Sent: Fri, May 21, 2021 6:40 am Subject: freeing memory in a shared library affects the performance of a program that uses it 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.
