Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.
It would be very nice to have the function shown above (at least for all of us that care about the execution speed of our VI and want to optimize the code), so you right away can see the totalt execution time of your VI in ms or even us.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Personally, I hardly ever time how long my VIs take to run. They take as long as they take, and as long as there is no performance issue, I really don't care how much time that is. I would be more inclined to agree with an idea which allows user to customize the toolbar or open various IDE tools at different times, which would then allow people who want to see the time to add that specific widget.
As a CLA I develop applications for my customers that are pretty big (the current project is >3000 VIs) and if we don't care about the performance we end up with a useless application. So for us timing is very important. To always open the Profiler is very annoying. Another way is to make a VI that you put in the beginning and end of the VI you want to measure that measures the time used between them. Would be so nice to have it built in instead.
I like the idea of a more graphical profiler that annotates the VIs directly. But I do NOT like putting that info on the toolbar in a permanent location.
Putting that in the standard toolbar would be bad for two reasons:
1. It would mean we would add timing tracking to every execution. Timing tracking hurts performance, so we don't want to have it always on.
2. It would encourage developers to care about performance, which is very VERY bad for code quality. Many studies that you can find in academic literature have shown the dangers of premature optimization. Repeatedly, programmers make bad code decisions in the name of performance that do not actually benefit their program's performance but often do make code more complex to debug or modify. Over-attention to performance is a danger to code. Performance optimizations for all but the most gross architecture decisions should be applied only after the functionality is complete and tested. There's a lot of discussion around this point, but most CS professionals agree with the legendary Donald Knuth of Stanford University: Premature optimization is the root of all evil.
I can see us annotating VIs somehow when you have profiler open, but I don't think putting it in the toolbar would be a good solution. Watermark on the VI maybe? Notes beside each subVI node for how long it took (like the exec highlight notes that appear on wires)? These seem reasonable to me. I just wouldn't reserve space in the toolbar.
The profiler comes with all the statictics I need to decide what to do: A seldomly called VI may - usually - take some extra time. Frequently called VIs can be identified easily by sorting by "# Runs" and get my attention. They are a candidate for a review regarding a performance improvement.
I am very satisfied with the performance gain(s) when following this workflow.
Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.