VI Analyzer incorrectly analyses SVN .svn-base files

[ChromaBurst]

I wanted to flag this behaviour. When you configure VI Analyzer to scan a directory that is under SVN control, the VI Analyzer incorrectly scans the base SVN files also. For example, the VI Analyzer makes no distinction between 32bitread_to_dsub.vi and 32bitread_to_dsub.vi.svn-base. You can select out the .vi.svn-base but we've found this tedious, especially with large applicaitions.

Is there any way the VI Analyzer can modified to search only for .vi files?

-Chroma

[Darren]

Hi Chroma,

There is no way to filter files based on file extension when using VI Analyzer 1.1.  Currently, the VI Analyzer looks at the file type (regardless of filename/extension), and if it is of the VI type, it will include it in the analysis.  I can definitely see how it would be useful to be able to filter the list based on filename or extension, though, and I will consider this for inclusion in a future version of the toolkit.

For now, you can replace the following file with the one I have attached to this post (usable with VI Analyzer 1.1 and later, LabVIEW 8.2 and later):

vi.lib\addons\analyzer\_vianengshared.llb\VIAnEng Add Folder to Engine.vi

This version of the file will only include files with the ".vi" extension in the analysis.  Here are a few caveats when using this modified file:

1.  Make sure you backup the _vianengshared.llb so you can replace it if you wish to have the original shipping functionality at a later time.

2.  This workaround requires that you do not expand the folders in the main VI Analyzer UI after adding them for the analysis.

3.  The workaround will not include .vit, .ctl, .ctt, or any other VI file types in the analysis...only ".vi" files will be included.

I hope this helps.  Thanks for using the VI Analyzer, and don't hesitate to post any other questions/feedback/requests to this forum.

Darren

[ChromaBurst]

Thanks Darren - your feedback and hotfix are greatly appreciated. We'll give the hotfix a try and let you know if we experience any problems.

Also, I haven't seen any documentation on this, but what is the minimum memory requirement for the VI Analyzer? We noticed when we run a complete sweep on our source tree about 1600 VIs, we see the application crash with a LabVIEW error. I'm assuming that reporting is not preiodically dumped to file during the analysis? Hence if you have a large source tree, you can potentially run into this memory problems. I've tested this on a desktop machine with 3GB and a laptop with 2GB, analysis time varied, but 6 hours was what it took to sweep the tree.

Can you confirm when the analysis is dumped?

-Chroma

[Darren]

Hi Chroma,

With VI Analyzer 1.1, all the analysis results are kept in memory until the analysis completes.  I have analyzed huge (10,000+ VIs) hierarchies in the past and not run into the issues you described, however.  I wonder if there is a specific VI being analyzed that is causing your crash.  Does the crash always occur at the same point in your analysis?  If so, I'd be interested to see if you could give me the VI that causes the crash so I could investigate it, or at the very least a pared-down version of the VI that causes the crash. 

I do agree that it would be handy to periodically save off the analysis results somewhere for logging and debugging purposes...this is a feature idea I've had for a while that I'd like to include in a future release.

Oh, and just so I have a more specific context for our discussion, what version of LabVIEW are you using to perform the analysis?  If it's 8.2 or 8.5, then a mass compile of the project\VI Analyzer and vi.lib\addons\analyzer directories will speed up performance.  It would also be a good idea to mass compile all the VIs in your application, if possible.

-D

[ChromaBurst]

Darren,

I'll send you full details of the crash, when available - yes, I should of mentioned in my previous post that I'd send them on! I'm using LabVIEW 8.2.1 on XP SP2. Good point about mass compile - I did this after I added your hotfix. I'll try running this again on our tree with all the MC's as you suggested and the hotfix.

Will let you know. Thanks.

-Chroma

[tst]

I'm not sure if this applies to the VI analyzer, but it's preferable to change your Subversion client to have _svn folders instead of .svn folders. LabVIEW itself ignores files and folders which start with an underscore, so this helps in all kinds of things. Of course, this will mean that you will have to delete your current working copy and check everything out again.

As I said, I don't know if the VIA follows this rule or not, but I'm sure Darren will be able to answer. I actually would not be surprised if it does not follow it, since I guess it works similar to the mass compile tool when given a folder and I seem to remember that doesn't ignore the _svn folders.

[ChromaBurst]

Good information, thanks!

-Chroma

[crelf]

Works great 🙂

[icastillejos]

I'm having the same problem with the mass compile function in LabVIEW 8.5.1. Is there a way to ignore this? perhpas a flag in the LabVIEW.ini file to ignore the files with extension svn-base?

Any help would be greatly appreciated...


Thanks,

<<N>>

[tst]

I don't know of any way to avoid this. You can do something like this:

1. Export all your code to another location.
2. Move the original code to another location.
3. Move the exported code to the original location, so you can be sure that you won't have linking issues.
4. Mass compile it.
5. Move it back.
6. Move the original code back to its original position.
7. Copy the new code over the old code, so that you still have all the svn files.
8. Commit.

You can do the same thing by deleting and checking out the existing code instead of moving it, but if it's a lot of code, I don't see the point. Just make sure you move everything together.