<div dir="ltr"><div>I found Linus' response from a previous question:<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div>There is some emerging technology (read somewhat 
under used and under tested) that can instrument processes. The support 
is in current master branch, but there is a branch where I started 
adding the <span class="gmail-il">instrumentation</span> calls.<br>branch: dev/add-process-<wbr><span class="gmail-il">instrumentation</span><br><br></div>Unfortunately the <span class="gmail-il">instrumentation</span> is invasive and requires modification of the processes but the overhead is minimal if <span class="gmail-il">instrumentation</span> is not enabled.<br></div>Once the <span class="gmail-il">instrumentation</span> calls are added, it can be activated on a per process basis via the process config in the pipe file.<br><br><span style="font-family:monospace,monospace">  process my_process<br>    :: my_process_type<br>    _instrumentation:type = logger</span><br>    <br></div>The above will enable the logger style <span class="gmail-il">instrumentation</span> which generates a log message for each start_*_processing() and stop_*_processing() call.<br></div>There
 is another one that uses RightTrack to generate execution time-lines 
for the processes, but that approach requires building an external 
package and other integration issues. This one has not been used is a 
while.</blockquote><div><br></div><div>Is the approach we are going to move toward? How ready is it currently? <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 15, 2017 at 12:59 PM, Matthew Leotta <span dir="ltr"><<a href="mailto:matt.leotta@kitware.com" target="_blank">matt.leotta@kitware.com</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">Linus should chime in here.  There is an instrumentation framework for exactly this sort of pipeline timing analysis.  Linus know the most about this.<div><br></div><div>—Matt</div><div><br><div><blockquote type="cite"><span class=""><div>On Nov 15, 2017, at 12:48 PM, Matt Brown <<a href="mailto:matt.brown@kitware.com" target="_blank">matt.brown@kitware.com</a>> wrote:</div><br class="m_-8844051834957845978Apple-interchange-newline"></span><div><span class=""><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We should generally not be using wall clock timing for performance measurement.</div></blockquote><div><br></div><div>Aren't there instances where wall clock time is relevant (e.g., total latency)? In a pipeline, where processing gets blocked until something finishes, it can be helpful to identify bottle necks.<br></div></div><br></div></div></span><span class="">
______________________________<wbr>_________________<br>Kwiver-users mailing list<br><a href="mailto:Kwiver-users@public.kitware.com" target="_blank">Kwiver-users@public.kitware.<wbr>com</a><br><a href="http://public.kitware.com/mailman/listinfo/kwiver-users" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/kwiver-users</a><br></span></div></blockquote></div><br></div></div></blockquote></div><br></div>