freeing memory in a shared library affects the performance of a program that uses it

Alberto Gcchelp
Fri May 21 10:40:45 GMT 2021

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 ( 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:,
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

More information about the Gcc-help mailing list