How can I profile part of an application?

[dsavir]

Hi,

I have an application with a LOT of subvi's. I would like to profile only a part of this, not the whole project. Can I use the profiler only on a particular vi and its subvi's, and not the whole project? I know the general area where there's a problem, I need the profiler to tell me which of about 15 subvi's is taking so long.

When I try to run the profiler as is it crashes LabView, so I can't just run it on the whole application...

Thanks for your help,

Danielle

[smercurio_fc]

I'm not personally aware of a way to configure the profiler to do this. You could try to use, instead, the "Memory Monitor" VI, as suggested in this post. If you look at the block diagram for that VI you'll see all the way to the left a "Get Memory Statistics" VI. It returns a list of all the VIs in memory. All you would need to do is filter this list. The output of this VI isn't as pretty as the profiler, but it should give you data you can work with.

As for the crash with the profiler, that's quite unusual. I've never had it crash on me, and I've used it on projects with hundreds of VIs. Could you be using it with VIs that have charts?

[Amanda_H]

Hi,

You could try using smercurio's suggestion or also try saving a portion of your project under a different name with just the subVIs you'd like to use. For the reference of every forum visitor, this KnowledgeBase article describes how to use the VI Profile Window.

[johnsold]

Danielle,

If you have a good idea of which VIs and subVIs you want to check, change their names to start with something like AAA_VI name. This will at least allow you to have them show up at the top of the Profiler window where you can examine their performance without scrolling through a long list. If some of these are vi.lib VIs, be sure to save them to a new location rather than changing vi.lib.

I am curious about crashing the Profiler also. I have never heard of that happening.

Lynn

[dsavir]

Hi all,

Thank you very much for all the suggetsions! I'll try them out.

About the profiler - whenever I press start (when the vi is running, when it isn't running, whichever subvi I open the profiler from) it crashed Labview. I have a number of charts in the program, but from what I understood from the post about charts, it isn't supposed to crash the profiler, just cause a memory leak.

Incidentally, I have a memory problem as well, so maybe if I find out what is causing the profiler to crash I'll also get to the root of the memory problem? Could the charts be the cause of all the problems?

Thanks,

Danielle

[Matt_W1]

The profiler also crashes on me in my large project (I was figuring it was something to do with have x controls, but that's a shot in the dark guess). What seems to help is opening the profiler before any of my vi's, then opening my main vi, starting the profiler and then starting the main vi, then ending the main vi (when I'm done) and stopping the profiler. The profiler seems to only work on vis in memory when it starts so if you open just the subvi's your interested in then start the profiler, then open your main vi and start that. But there'll still be a lot of extra vi's in the list.

If you weren't aware, you can click on the column header's in the profiler window to sort by that column.
Another option would to save the profile (it's just a tab delimited file), then you can use a simple vi to load and filter out the relavant names.

Matt W


Message Edited by Matt W on 01-16-2008 03:23 PM

[Amanda_H]

Hi,

Here is a suggestion for memory management. This may or may not correct your problem, but I thought it was worth a shot!

[dsavir]

Hi,

Thanks for your help!

I tried all of the suggestions here about the profiler:

1) When opening only the subvi I'm intereseted in, then starting profiler, then running main vi - the profiler crashes labview when I press "snapshot" after my main vi has stopped running.

2) When opening the profiler, opening main vi, running profiler, running main vi - profiler crashes labview when pressing "start".

3) The Memory Monitor: This works, but it is not what I'm looking for. I have a piece of code that is taking more than 30 seconds to run. I am trying to find out what is taking so long. I do not think that the memory of each vi is necessarily an indicator of this, as I think the problem is that a calculation is performed too many times. I took note of the heavy memory vi's though, and I will check them out.

Also, I do not have x controls, so that is not the cause of the crash.

Does anyone have another idea how to find what is taking more than 30 secs?

Thanks,

Danielle

[F._Schubert]

An idea to make a profiler yourself:
Use a kind of Action Engine, each time it is called, it appends the timestamp or tick count on an array, as well as the call chain.
Drop that on various places you want to monitor.
After running your app, you now can examine which portions of your could were executed latest.

It's not as nice as having the profiler working, but is propably faster to code. And you actually can expand that profiling AE with other information via VI Server (Get info about Application or Calling VI), as you approach your speed/memory issues.

Felix

[smercurio_fc]

"I have a piece of code that is taking more than 30 seconds to run." ... "Does anyone have another idea how to find what is taking more than 30 secs?"

What is the piece of code that is taking 30 seconds actually doing?