<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 9, 2016 at 3:59 PM, Max Lapshin <span dir="ltr"><<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Maybe I'm doing something wrong (processes are running outside of  in/out) or reductions are calculated somehow else, for example some bifs or io are adding more reductions to global statistics?<br></div>















</div>
</blockquote></div><br></div><div class="gmail_extra">There shouldn't be any extra reductions from processes running in secret, or bifs etc.</div><div class="gmail_extra"><br></div><div class="gmail_extra">There is however an inherent gap from where you will be miss reductions from when a process starts until you read the first reductions. Since process_info(Pid, reductions) needs the process' main lock, you have to wait until the target process finished executing until you get the reduction info, so you will be about 2000 reductions late. During this time the tracing process will be suspended, so it will be even longer until you are able to get the initial reduction count for the remaining processes. To get around this, maybe you just want to do a [{Pid, process_info(Pid, reductions)} || Pid <- erlang:processes()] to get the initial reduction count instead of reacting on trace messages.</div></div>