<div dir="ltr">Hello,<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 27, 2018 at 10:11 PM Devon Estes <<a href="mailto:devon.c.estes@gmail.com">devon.c.estes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I hope this helps jog some ideas as to what might be going on here, and thanks again for any help y'all can offer.</div></div></blockquote><div><br></div><div>I think I have figured out what is going on. It seems to be the allocation of the term containing the garbage_collection_info that is messing with measurements. I'll try to change the code inside process_info to give a more accurate view of the current memory usage, however as long as the call to process_info happens in the process doing the call there will be some miss match.</div><div><br></div><div>I would suggest that you instead do a call to erlang:garbage_collect() before and after the benchmark is run and rely on tracing to get the correct information. Alternatively you could call erlang:process_info on the process from the trace collector, though then you would need some type of synchronization in between the processes.</div><div><br></div><div>I have not been able to reproduce the scenario you mentioned where the heap_block_size is increased without getting a trace message. What code did you run to trigger that? As always an Erlang example would be preferable, but I should manage with an Elixir one as well.</div><div><br></div><div>Lukas</div></div></div>