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

[johnsfine@verizon.net]

Maybe deleting those objects causes some other effects like destroying
memory pools, which then alters the behaviour of the rest of the program.
The Gmsh devs are in the best position to analyze it and explain it (and
maybe solve it).
 I find the word "destroying" misleading there.  Destroying might mean "corrupting", which bugs in a library could do (and which could be sidestepped by eliminating that call to free memory from the library code).  But the symptom would be a crash in later code, not just a slow down.
I expect what is happening is "Fragmenting" the memory pool.  Maybe you meant that.  I'm just objecting to the word "destroying", especially if the OP is hoping for help from the Gmsh devs.
The way Gmsh might fragment the memory pool is by alternating the allocations of objects that will be cleaned up before exit with the allocation of either objects whose ownership will be passed back to the caller, or objects that are memory leaks.  So if someone asks for their attention, I think it should be with that theory in mind.  If you are allocating many objects that will be cleaned up before exit as well as many objects whose ownership will be passed back, it is better practice to somehow segregate them to avoid fragmenting the memory pool.  But unless the library is designed to be the beginning of very performance critical programs, that might be more than is reasonable to ask of library developers.
Memory fragmentation can drive the working set of the program way up, causing a direct slowdown on a system with barely enough ram for the task..  But if that were the case here, then the kludge of not freeing the temporary objects would have made the slowdown a bit worse, rather than making it better.
The GNU routines for managing the pool of free memory should expect and deal with memory fragmentation, and avoid the reported slowdown.  That is difficult to accomplish, but several very smart people have worked on that, and I thought it was a solved problem.  But those routines handling this situation very badly is the only theory I can think of that fits the described symptoms.
If a collection of objects returned by the library function are forming the dividers in the memory pool, then some form of deep copy of that data (followed by deleting the original) would clean the memory pool.  But doing that simplistically might not work (might just do a tiny phase shift of the same fragmentation).  Copying it all to some contiguous data structure (then deleting the original) is the most reliable simple solution.
My one theory suggests several different approaches to solution or mitigation:
1) Accept that the memory pool is fragmented in a way that slows the GNU routines for managing that pool.  Reduce/change the number of memory allocation / release cycles in the later code (the part that is slow now) so its performance is immune to the fragmentation.
2) Look for (sorry about mistyping that in my earlier reply) an alternate version of the routines managing the free memory pool (a few were available years ago, when I had this same problem).
3) Copy the output of the Gmsh and free the original, in a way that cleans the memory pool.
4) Get Gmsh devs to fix the flaw.
5) Get devs of the GNU code for managing the free pool to fix the flaw.
 
 
-----Original Message-----
From: Jonathan Wakely via Gcc-help <gcc-help@gcc.gnu.org>
To: Alberto Gcchelp <alberto.gcchelp@gmail.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Sent: Fri, May 21, 2021 7:56 am
Subject: Re: freeing memory in a shared library affects the performance of a program that uses it

On Fri, 21 May 2021, 12:24 Alberto Gcchelp via Gcc-help, <
gcc-help@gcc.gnu.org> wrote:

> 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.
>


The explanation is clear and your English is faultless.


>
> Why does deleting temporary objects in a shared library affect the
> performance of an unrelated part of the program? Does that make sense?
>


That is surprising, but you should talk to the Gmsh developers about it.

Maybe deleting those objects causes some other effects like destroying
memory pools, which then alters the behaviour of the rest of the program.
The Gmsh devs are in the best position to analyze it and explain it (and
maybe solve it).