Programming performance melt down

[Omar Mussa]

I'm sure this has been raised before but I hit the wall of frustration today. I have a project with about a dozen classes and minimal inheritance is being used. However, most of my classes have references to other classes in their class data. The problem I face is that every time I make a change to my block diagram, I have to wait about 60 seconds for LabVIEW due to the overhead/recursion/etc. of LabVIEW checking ALL of my classes to see if anything is broken and if so if other classes are broken as a result. Now, this can really suck, especially if all I do is an operation such as add an element to my 'Unbundle by Name' (wait 60 sec) wire the element to another node (wait 60 sec) etc. It basically can result in LabVIEW becoming 'unusable' by me or really anyone else. Its ridiculous and while it is functionally working (i.e. it doesn't break my diagrams in unexpected ways) it is not functional in any other practical way. I guess this is a rant because I can't submit this as a 'bug' to NI (it isn't a bug) and yet this is pretty close to stopping me in my tracks.

[crelf]

QUOTE(Omar Mussa @ Jan 30 2008, 12:55 PM)

I guess this is a rant because I can't submit this as a 'bug' to NI (it isn't a bug) and yet this is pretty close to stopping me in my tracks.

It might not be a "bug", but it's certainly an "issue" - I'd still submit it anyway: that way NI can know that it's an issue that stopping you from doing your work and, worse still, stopping you from using their product.

[jdunham]

I'm just curious how you debug your code with all of those objects? I tried a few applications with objects, but I quickly found out that one can't see the data on the subvi front panels. It ended up taking me so much longer to debug the application than it does when I use regular old typdef clusters. If you are not using the benefits of inheritance, then there is even less reason to use them.

As far as it being very slow, thanks for the heads up, and good luck getting some resolution. Is there anything in your objects like a DAQ or VISA refnum which might have a lot of overhead attached to the control?

[TobyD]

Just curious...what kind of system are you running on (processor, memory, etc)?

[Omar Mussa]

QUOTE(jdunham @ Jan 30 2008, 10:14 AM)

I'm just curious how you debug your code with all of those objects? I tried a few applications with objects, but I quickly found out that one can't see the data on the subvi front panels.

I'm using a ByRef framework (Endevo's but I have seen this problem on the OpenG Classes as well) on top of my LVOOP objects that makes the object data literally a cluster. All of my data access is via 'Get' and 'Set' attributes which basically unbundles/bundles the cluster data into the LVOOP object. The way you will get around your problem of not seeing the data is by creating accessor VIs -- then you can easily probe your object data and life is good again (in my opinion). QUOTE(jdunham @ Jan 30 2008, 10:14 AM)

It ended up taking me so much longer to debug the application than it does when I use regular old typdef clusters. If you are not using the benefits of inheritance, then there is even less reason to use them.

I'm using inheritance for some of the classes in my system. But I also highly value being able to encapsulate my code. So far, the LVOOP objects are great for that purpose. The biggest problem I see with them from a high level perspective is not being able to create tests for my private VIs outside of my class. Debugging is not an issue for me. QUOTE(jdunham @ Jan 30 2008, 10:14 AM)

As far as it being very slow, thanks for the heads up, and good luck getting some resolution. Is there anything in your objects like a DAQ or VISA refnum which might have a lot of overhead attached to the control?

That reminded me that I recently added some IMAQ image refs to my data, I will see if replacing them helps. I think the biggest problem is having the classes referencing other classes in their object properties. The recursive checking for errors seems to be the biggest issue (in classes in my project that do not reference other classes in their class data, I don't see the performance issue at the moment). Luckily, I have one 'application' class that has references to the other major classes in my application and it seems to be the only one that is really painful (so at least I'm learning to see where I can 'avoid' the problem).QUOTE(crelf @ Jan 30 2008, 10:08 AM)

It might not be a "bug", but it's certainly an "issue" - I'd still submit it anyway: that way NI can know that it's an issue that stopping you from doing your work and, worse still, stopping you from using their product.

Ya, ok will probably do so -- but the pain is knowing that to get any true progress I'll have to recreate the problem in a simpler way and that is enough to make a procrastinator wait until the project is over

[crelf]

QUOTE(Omar Mussa @ Jan 30 2008, 01:33 PM)

...the pain is knowing that to get any true progress I'll have to recreate the problem in a simpler way and that is enough to make a procrastinator wait until the project is over

You can upload the whole damn project to NI and then give them a few simple steps on reproducing (what you uplaod doesn't need to be simple), but that all depends on whether you're comfortable with giving NI your code...

[MikaelH]

Hi Omar

I've never experiensed this kind of delay when updating my attributes using the Endevo classes.

But I got alot of crashes in 8.21 when attribute (type-defs) has other classes public type-def inserted in them.

Currently I'm working on 5 projects using from 5-30 Endevo Classes in them but that is in 85 and I'm NOTusing IMAQ references.

You could try to drop your project file and create a new empty project and add the files one by one again.

Cheers,

Mikael

[Dirk J.]

The only annoyance I have is the loading time it takes to load all the classes and their dependencies when opening a project.

Otherwise, my 30+ class projects work fine, even with DAQ references in object data.

[Aristos Queue]

a) Are you using LV8.2? 8.2.1 fixed a couple items along these lines.

b) In both 8.2 and 8.5: Do you have the VI Hierarchy window open while you're working? If your number of VIs in memory is large, close that window. (It's a known issue and is being addressed.)

These are the only issues of this type that have been reported to my team.

[Omar Mussa]

QUOTE(Aristos Queue @ Jan 30 2008, 11:03 PM)

a) Are you using LV8.2? 8.2.1 fixed a couple items along these lines.b) In both 8.2 and 8.5: Do you have the VI Hierarchy window open while you're working? If your number of VIs in memory is large, close that window. (It's a known issue and is being addressed.) These are the only issues of this type that have been reported to my team.

a) I'm using 8.5.b) I NEVER open the VI Hierarchy anymore -- it basically forces me to kill LabVIEW when I do. I'm not sure how many total VIs are in my project. I found a quick way to find the number of VIs that are directly shown in my project (Project --> File Information --> Export Files ...) which I opened in Excel and found 560 files. I know there are more that are being called by these VIs but are located in VI.lib or user.lib.I tend to keep a VI Tree of my project open while developing code -- it seems like it keeps the everything from having issues later when I try to save and apply type def changes, etc. I tried restarting LV and not opening the VI Tree and I had the same problem (it seems to affect my main application class the most).QUOTE(jdunham @ Jan 30 2008, 10:14 AM)

As far as it being very slow, thanks for the heads up, and good luck getting some resolution. Is there anything in your objects like a DAQ or VISA refnum which might have a lot of overhead attached to the control?

I have replaced my IMAQ refnum with a String and I'm not seeing any difference (but I do feel like that was still a good suggestion/idea).