Troubleshooting performance issue when running vi using project provider

[antsundq]

Hey,

I have a funny little problem and need some help troubleshooting an issue I am seeing.

I am calling a VI which takes an application ref and a file path and runs all unit tests within the lvproj-file at the file path.

I also have a project provider vi which enables me to run the same action from the right-click menu of a .lvproj-file in my project.

The code for it looks like this:

The VI on the left is part of LabVIEW and gives me a reference to the project item which launched the action.

This works functionally, but the problem is that it is very slow if I run it with the nested project originally closed. If I first open the nested project and then run the tests in the same way it is near instant.

Opening the project does take some time, but it cannot account for the whole problem. If I open the nested project and call the same entry point it takes around 8 seconds, which mostly is due to load time. When running using the right-click menu with the nested project originally closed, it takes about 30 seconds.

It seems to me that opening and loading the project file from the project provider right click menu adds a significant overhead, but I have been unable to figure out why.

I'm greaful for any advice or ideas on how to troubleshoot this. 

[tst]

I don't really have experience with this, but I would suggest starting from checking which part of the code is the one that actually takes the time. That will at least give you an idea of where the problem is.

Once you have that, check if it behaves the same when it's not running from a project provider. If it's better there, then maybe you could use the provider just to run the code in another context. If it's not better there, then maybe it's a general problem and you would have to see if there's a faster way of getting it (for example, by using the Open Document method and polling the Projects[] property or something even uglier).

[antsundq · Accepted solution]

Thanks for the reply. 

I have not benchmarked it yet, because it seems like the issue is not in the code itself. The problem is how LabVIEW loads stuff into memory and in some cases compiles.

You are right about having to do something rather ugly with picking the application instance. I tried everything I could come up with the brute force way, but I now think I have a solution.

What I'd like to do is to emulate what happens when I manually open the project and then run the tests through my project provider entry point. When I run it this way, the performance is good for some obscure reason. I also need to be mindful so that dependencies in the active project are locked and released to avoid file corruptions, which I managed to get at one point.

Anyway, I found a scripting method named Open LabVIEW Documents. According to its description, this method does the same as File >> Open.., so it was kind of what I was looking for. 

If anyone has an explanation to why this works differently than my first approach, I'd be eager to learn.

[JÞB]

In my experience it actually the UTF itself that takes quite a bit of resources to launch the first time.

I suspect that several VIT instances are spawned and left with dataspaces in memory after first launch. ACBRs of preallocated clones might improve performance under the hood. But, the UTF PREDATES the ACBR node.

[antsundq]

Yes, but I am not using UTF, so that is probably not why.

The feature I'm working on is for LUnit:

LUnit Toolkit for LabVIEW - Download - VIPM by JKI