<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 21, 2015 at 10:08 PM, Simon Thompson <span dir="ltr"><<a href="mailto:s.j.thompson@kent.ac.uk" target="_blank">s.j.thompson@kent.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>I see that discussions have already aired filtering, and I think that the main lesson for me from RELEASE was it’s crucial to find ways to deal with torrents of potential data. It’s no good to generate trace info which is filtered out downstream: if it can be filtered at source, so only generated when required, then that would be great.</div></div></blockquote><div><br></div><div>Filtering close to the source is indeed important. My hope is that if you can implement the tracer as a nif, you can in the backend inspect the data that is to be outputted without having to copy it anywhere and from there make smarter decisions on what you actually want to trace on. We still need match specs to do the initial filtering from erlang, but for those of us having to deal with very specific tracing scenarios we could write a specialized backend that takes care of the filtering. Unfortunately I have not yet come up with a way to make the tracer backend be a pure erlang module and still be fast.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Another facility which may be problematic to implement, but which could be really helpful, would be mechanisms to aggregate information as part of the BEAM: e.g. to be able to emit a trace message every time 1000 messages have passed from process A to process B, or node A to node B. Again this would push into the infrastructure something that currently needs to be done in trace processing.<br></div></div></blockquote><div><br></div><div>My hope is again that the more flexible nif tracer backends will help in creating sampling profilers. If for instance you want to only trace the stack of every 1000th call, you would just have a counter in the nif backend and extract the stack only if you need it. There will of course be some overhead, but it will be minuscule compared to what there is today.</div></div></div></div>