DEV Community

Cover image for Cables vs. malloc_trim, or yet another Ruby memory usage benchmark

Cables vs. malloc_trim, or yet another Ruby memory usage benchmark

Vladimir Dementyev on March 19, 2019

Single line, big promise Memory usage has always been one of the most discussed performance-related topics in the Ruby community. Last ...
Collapse
 
millebi profile image
Bill Miller

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.

Collapse
 
palkan_tula profile image
Vladimir Dementyev

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

Collapse
 
joshcheek profile image
Josh Cheek • Edited

This is a super awesome idea ^_^
(describing all the contributions)

Collapse
 
ksec profile image
ksec

Really wished it had included AnyCable's benchmarks at the end.

Collapse
 
palkan_tula profile image
Vladimir Dementyev

Added)