[erlang-questions] Turn off Garbage Collection for a time

Dmitry Belyaev be.dmitry@REDACTED
Thu Jun 2 01:24:48 CEST 2016

As we know in Beam GC might not run at all for processes that have enough heap to operate until their end. And some optimisation techniques suggest using that possibility.  

The tests that hit GC only eventually give us average estimates for that particular setup that have those particular GC properties like consumed and available heap sizes. They are not that much helpful for any real application where those GC parameters will be different. That's why we always receive replies to measure in the real system. 

On the other hand if we force GC during a benchmark we measure high limit that includes possible GC pressure. This way we can predict that system won't consume more resources than in the benchmark.

But that doesn't give us clues how system would behave if we optimise it so it doesn't GC at all.

On 2 June 2016 8:05:02 AM AEST, "Richard A. O'Keefe" <ok@REDACTED> wrote:
>On 1/06/16 6:47 PM, Tobias Pfeiffer wrote:
>> Why would I want to do that? I'm working on a benchmarking tool and I
>> don't want garbage collection to mess with my measured execution 
>> times. I run them multiple times and standard deviation goes way up 
>> because usually GC triggers during one run of n.
>I know that trying to avoid GC during benchmarking is a common
>but I invite you to think very carefully about the point of doing a 
>If the thing you are measuring allocates memory, then that memory will
>to be reclaimed somehow, and that's GC.  So if you *don't* include GC
>in your measurements, you will be (unintentionally) deceiving anyone
>relies on your results about the true costs of using whatever it is.
>So why not go in the other direction?  Run the benchmark LOTS of times
>so that you get lots of GCs?  If you run the benchmark 100 times and
>7 GCs, then each run incurred 7% of the GC time, even if a GC didn't
>happen to occur during that run.
>(I've been looking at some papers recently that basically did this, but
>the point of those papers was to evaluate GC algorithms...)
>erlang-questions mailing list

Best wishes, 
Dmitry Belyaev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160602/2e876623/attachment.htm>

More information about the erlang-questions mailing list