<html><head></head><body>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. <br>
<br>
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. <br>
<br>
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.<br>
<br>
But that doesn't give us clues how system would behave if we optimise it so it doesn't GC at all.<br><br><div class="gmail_quote">On 2 June 2016 8:05:02 AM AEST, "Richard A. O'Keefe" <ok@cs.otago.ac.nz> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><br /><br />On 1/06/16 6:47 PM, Tobias Pfeiffer wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br /> Why would I want to do that? I'm working on a benchmarking tool and I<br /> don't want garbage collection to mess with my measured execution <br /> times. I run them multiple times and standard deviation goes way up <br /> because usually GC triggers during one run of n.<br /></blockquote>I know that trying to avoid GC during benchmarking is a common practice,<br />but I invite you to think very carefully about the point of doing a <br />benchmark.<br />If the thing you are measuring allocates memory, then that memory will have<br />to be reclaimed somehow, and that's GC. So if you *don't* include GC time<br />in your measurements, you will be (unintentionally) deceiving anyone who<br />relies on your results about the true costs of using whatever it is.<br /><br />So why not go
in the other direction? Run the benchmark LOTS of times<br />so that you get lots of GCs? If you run the benchmark 100 times and get<br />7 GCs, then each run incurred 7% of the GC time, even if a GC didn't<br />happen to occur during that run.<br /><br />(I've been looking at some papers recently that basically did this, but <br />then,<br />the point of those papers was to evaluate GC algorithms...)<br /><br /><br /><hr /><br />erlang-questions mailing list<br />erlang-questions@erlang.org<br /><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br /></pre></blockquote></div><br>
-- <br>
Best wishes, <br>
Dmitry Belyaev</body></html>