I wonder what would happen if the malloc_trim was run, say every 100 GC's? Constantly returning memory being slow makes some sense, so maybe if the return of the memory was less often and only after "it's sure" that it doesn't need the memory may be useful.
I would also be interested in running a cyclic test: Run at high load, drop to a more common lower load for a while, and then go back to a higher load... cycle like a common application would see in typical usage. I wonder if the memory usage would become something interesting.
I wonder what would happen if the malloc_trim was run, say every 100 GC's?
Yeah, that's something I was thinking about, too. Maybe, more sophisticated approach could be more efficient (either calling every N full cycles or depending on the number of allocated pages or whatever).
So, maybe, the best option would be to add GC.trim and let users decide when to call it (the same way it's proposed for GC.compact).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I wonder what would happen if the malloc_trim was run, say every 100 GC's? Constantly returning memory being slow makes some sense, so maybe if the return of the memory was less often and only after "it's sure" that it doesn't need the memory may be useful.
I would also be interested in running a cyclic test: Run at high load, drop to a more common lower load for a while, and then go back to a higher load... cycle like a common application would see in typical usage. I wonder if the memory usage would become something interesting.
Yeah, that's something I was thinking about, too. Maybe, more sophisticated approach could be more efficient (either calling every N full cycles or depending on the number of allocated pages or whatever).
So, maybe, the best option would be to add
GC.trimand let users decide when to call it (the same way it's proposed forGC.compact).