LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
Showing results for 
Search instead for 
Did you mean: 

Color Shading and Inserting Text to Profile VIs Visually

What bugs me about the VI Profiling Tool is that it is not intuitive.  The information it provides is really useful; however, it's so hidden and difficult to interpret that few people actually know where it is to use it.  Let's say you are simply acquiring data using DAQmx and writing that data to a file, as below:


Block Diagram of Inefficient DAQmx and File I/O


You might want to find out how to make this more efficient, but the only way you know is to insert Tick Count VIs and wrap your wires through sequence structures to do it.  It's annoying, and there are other ideas from JackDunaway (here) and JohnMc19 (here) which aim to simplify the use of those VIs. 


But why re-code your application when the VI Profiler can do it for you?  In addition, the VI profiler has more timing information (longest, shortest, average, total, etc) as well of number of runs and memory allocation data.


Good news: VI Profiler makes getting the data easy. 

Bad news: VI Profiler makes using the data difficult.


Why Using the Profiler is Difficult


First, you need to know it exists among a number of bland and condensed gray menus (Tools>>Profile>>Performance and Memory).


Next, you have to coordinate starting the profiler with starting your VI (start the Profiler, then start your VI, then stop your VI, then stop the Profiler).


Finally, you have to dig through a TON of VIs to find the ones that are relevant (I assume this is because, for polymorphic VIs, all of the instances are loaded into memory, even the dozens that aren't currently being used.)


When you find the VI you wish to examine, it will look something like this:


VI Profiler Currently


Have fun sorting through that!  When I finally find a VI that's hogging memory or speed, I'd expect to click on it to navigate to that VI.  NOPE!  All the VI Profiler does is make the line bold.  Not particularly easy to use...


I can't say if it's possible to get rid of VIs that aren't being used, or to make the menu option more visible to the user, but I do have an idea or two for how to make this information easier to understand in LabVIEW.


So here's what I suggest:

Adding a couple of check-boxes to the top of the VI Profiler will view in relation to your LabVIEW VI.  Notice the extra check boxes in the top of this image. 


VI Profiler With Color Shading


One checkbox allows you to color the column you wish to highlight in your LabVIEW code.  The other checkbox inserts a text comment containing the highlighted data straight into you LabVIEW code (right next to the sub VIs):


Shading SubVIs According to Relative Execution Speeds

From the above picture, you can clearly see the Write to Spreadsheet File VI is the slowest to execute.  Next in line are the Start DAQmx Task VI and then the Stop DAQmx Task VI.  So if a developer wanted to find out how to make his loop run faster (and therefore increase the rate data is read from his PC RAM), he would know the VIs that are more red are the ones he needs to focus on first.


Also, if a user wants to highlight the memory usage, he could select a memory column from the VI Profiler.


Highlight Average Memory Usage Per VI 


Then the LabVIEW block diagram would look like this:


Block Diagram Shaded in Blue for Average Memory Usage

In this case, if a developer wants to find out how he can optimize his code for memory usage, he knows where to start.


Side-note: I think selecting multiple colors at a time (one for each column of data you wish to highlight) would be cool, but that would start to get messy on the block diagram.


Other data, like the number of runs, could highlight which sections of code are running more often than others.


If we integrate the VI profiler more effectively into LabVIEW, there are a lot of benefits:


1. Re-coding to find timing specs won't be necessary for Sub-VIs

2. Monitoring memory allocations much easier (some users don't know it's possible with LabVIEW).

3. When there's a problem, it's easier to understand which SubVIs are slowing down code or hogging their memory.

4. Developers can further code development WHILE being wary of inefficiencies.

5. More integrated development environment "feel" for new customers or the experienced G-coder.


Please let me know what you think!

National Instruments
Active Participant

Brilliant idea! May many kudos cross your path.


In regards to your side-note:

I think that selecting multiple columns could work, and here's how: Instead of having many different colors (as you said, that would get ugly), it would only be one color. Selecting multiple columns would put each piece of information in the label near the subVI, and the color intensity would be an overall "badness" of the subVI.


The badness could be an aggregate, perhaps weighted, perhaps not, of each of the selected columns. Also, this "Badness" would be displayed in the label. 0 is not bad, +inf is superbad.



If the user selected Avg Mem and Avg Run Time:

with bad.png


You'll notice that some VI's have the same Badness number: the weighting determined that they are essentially equal - one is faster but takes more mem, the others slower, but are more memory-efficient. (Ok, really, they are the same because I got lazy...)


If you REALLY wanted to make it customizable, you could let the user determine the weight of each profiler column. Some people don't care how much memory it takes, as long as it's fast. Others are the opposite.

Knight of NI

I agree. This is a great idea.


I like the idea of color shading and displaying the metric as a tooltip beside the subVIs on the diagram.


Just FYI, if you double-click on a VI name in the profiler, it will expand the entry to show all the subVIs and their metrics when called by this VI.  Does this help?


Thanks for bringing that to my attention--I didn't realize that was there!  From an intuitive standpoint, there's no reason for me to believe that clicking on the line and clicking on the VI name, specifically, would have different effects.  Either way, I still hate the listbox format.  I think the color shading will be a world of difference for using this tool.


While we're on the topic of sub-VIs (I didn't want to bring this up in the article, but I guess I'll mention it here.)  What I'd REALLY like to see is double-clicking on a VI on the block diagram opens the subVI, which has its own block diagram shaded with relative intensities, as well.


This makes the situation a little sticky, because I'm not sure if shading in subVIs should be absolute or relative.  I can see users wanting either, for a couple of reasons:


1) Relative Shading within Sub-VIs - what I mean by this is that all the sub-VIs on a single block diagram are only shaded in reference to other sub-VIs on that same block diagram.  This is most intuitively understood by looking at the images in this article.  


Good news - you can focus on just one block diagram at a time, so it's straightforward.

Bad news - you could be so focused on one dark red sub-VI on one block diagram, you're missing a bigger resource hog under a different sub-VI.


2) Absolute Shading within Sub-VIs - in this case, the subVIs on a single block diagram are shaded not only with respect to each other, but also with respect to other VIs loaded in memory (all VIs loaded under a single top-level VI, for instance).


Good news - You can compare different sub-VIs to each other and find out which is the bigger resource hog.

 Bad news - It may be confusing to a user who only wants to concern himself with one VI at a time.


I know this addendum adds a little more complexity, but I'm hoping it doesn't take away from the original idea.  Whether to use absolute or relative shading could probably just be an extra option within the preferences.

National Instruments
Active Participant

Neat idea. I was thinking that the shading and the metrics display could get messy quick. How about a badge on each VI with a simple colored bar showing the relative value of each selected column. When you are looking at this stuff, it's less important what the actual numbers are than what they are in relation to others. Also, this way you could select multiple metrics and see them all at the same time.


Ooh...nice idea...the color bar would definitely resolve that issue.


I still tend to think the metrics are important, but the color bar would make things easier to compare when actually analyzing the VI.  Because shading a VI is more visually engaging, it is better for understanding what's happening at-a-glance.  However, once you start to think about which subVI is executing more slowly relative to others, the color bar definitely takes the cake.

National Instruments

C. Minnella -- I liked your suggestion so much, I thought I'd include an image of what that might look like:


DAQmx File IO Block Diagram Speed and Memory Bars.png

After playing with this, I realized that there will probably be some additional questions about how to position the bars (above, below, to the side) relative to the subVIs.  I think just as long as the coloring acts as a "mask" (that is, you can easily make the bars visible and invisible, and you can't interact with them), then it should be pretty easy to incorporate them without sacrificing visibility of the code.

National Instruments
Active Participant

I prefer showing the actual data instead of the slider bars... no sense hiding data.  If you want a graphical approach, maybe you could set a 'maximum time' and 'maximum memory' value to each VI and then the color of the text could change as you approach and surpass those limits.

-John Sullivan
Analog Engineer