<div dir="ltr">The current process instrumentation support is functional and I is in master. Most of the processes have been modified to implement the instrumentation calls. The logger instrumentation provider just log messages at the start and end events for each process entry. A new implementation could be created that would give elapsed (CPU or other) time for the process method.<div><br></div><div>Maybe this is the time to revive the RightTrack application and use that for timing analysis. It has been languishing for quite a while and could use some UI and functional improvements.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 15, 2017 at 1:05 PM, Matt Brown <span dir="ltr"><<a href="mailto:matt.brown@kitware.com" target="_blank">matt.brown@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 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="m_-3764250946034326792gmail-il">instrumentation</span> calls.<br>branch: dev/add-process-<span class="m_-3764250946034326792gmail-il">instrumentatio<wbr>n</span><br><br></div>Unfortunately the <span class="m_-3764250946034326792gmail-il">instrumentation</span> is invasive and requires modification of the processes but the overhead is minimal if <span class="m_-3764250946034326792gmail-il">instrumentation</span> is not enabled.<br></div>Once the <span class="m_-3764250946034326792gmail-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="m_-3764250946034326792gmail-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="HOEnZb"><div class="h5"><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><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_-3764250946034326792m_-8844051834957845978Apple-interchange-newline"></span><div><span><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>
______________________________<wbr>_________________<br>Kwiver-users mailing list<br><a href="mailto:Kwiver-users@public.kitware.com" target="_blank">Kwiver-users@public.kitware.co<wbr>m</a><br><a href="http://public.kitware.com/mailman/listinfo/kwiver-users" target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/kwiver-users</a><br></span></div></blockquote></div><br></div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Kwiver-users mailing list<br>
<a href="mailto:Kwiver-users@public.kitware.com">Kwiver-users@public.kitware.<wbr>com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/kwiver-users" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/kwiver-users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font color="#888888"><b>Linus Sherrill - </b></font><font color="#888888">Staff R&D Engineer<br></font><font color="#888888">Kitware, Inc.<br>28 Corporate Drive<br>Clifton Park, NY 12065-8662<br>E: <a href="mailto:linus.sherrill@kitware.com" target="_blank">linus.sherrill@kitware.com</a><br>P: 518.881.4400<br></font></div></div></div></div></div>
</div>