LabVIEW editing running slow

[SeanJ]

I'm queringy all the tables in a database to return a screen to the user that shows the full details of an item.

In the VI, once I delete a wire, it takes about three seconds for it to actually delete.  There's a fair bit of data in the database cluster and the VI takes up about 2MB.

I've used a simple state machine with 16 states, 14 of which are as shown below with different tables being queried and some with four with query arrays.

 

The orange section is a subVI.  So really all there is in the VI are the Display controls and the output cluster.

I am using a machine with i7 6700HQ @2.6GHz, 8GB DDR3 & 4GB GTX 950M.  I would have thought it could handle a VI of 2MB and in fact LabVIEW is only taking up about 15% of the CPU with the majority of it idle.  There is lots of spare memory.  I should have a new PC next week with a GTX 6GB 1060, i7 & 16GB of DDR4 but am concerned that maybe the issue s due to a LabVIEW resource setting rather than the PC itself.

Does anyone know why this particular VI would cause such an issue with editing and can I direct LabVIEW to use more processor / memory??

[Mark_Yedinak]

What version of Windows are your using? IN this day and age 4 GB of ram is the bare minimum that will run Windows, let alone using other applications. Windows is a pig and I would never try to run it with less than 8 GB. I don't see anything inherently wrong with your VI and have not experienced these types of issues on VIs that I edit. Many which are more complex than what you have above.

Now, without seeing your actual code there may be some things you can do to help. You mentioned that your cluster is quite large. Can you break this up into smaller clusters and work with smaller pieces of data at one time? This may or may not help but very large structures can cause performance issues if lots of copies are being made.

[SeanJ]

HI Mark,

I'm using windows 10 pro.  I've 8GB of RAM, as said I am moving to a new laptop next week with 16GB RAM but given there's loads of spare memory as is, it's almost as if LabVIEW is throttling itself.

It's probably not great to write values via a property node but the slowness happens even when I am just editing and after a system reboot.

I'm confused 

[Mark_Yedinak]

Yes, property nodes will slow things up. Do you have other things running in parallel to this code? Depending on the complexity of the block diagram some edits can take time for LabVIEW to rewire everything and recompile the code. I don't think this is fundamentally a LabVIEW issue. Remember LabVIEW will recompile the code any time a  change is made. It also needs to rewire objects when things are deleted. There is a a lot going on under the hood. Can you post a video showing the delay? It may help to see if something can be done to minimize this. Seeing the actual code would also help if that is possible.

[paul.r]

The VI is 2MB?? Whats in it? Thats a huge VI.. That alone could be a big part of the problem.

Are you using LVOOP? Do you have circular dependencies in your code?

[JÞB]

Let me try to restate your problem:

You have a vi in memory that does not edit quickly:

1. What Tools do you have installed? There may be a "Framework Conflict"
2. From Tools>> Options>> Reduce the number of undo steps per vi from the default 99 to something like 25 (The undo stack keeps a copy of the data on the wires per edit)

[RavensFan]

Also.  If you have large block diagrams and the navigation window open, it can take longer to modify as LabVIEW spends a lot of time figuring out how to redraw the block diagram in the navigation window.

[SeanJ]

Hi Jeff et al.

I tried reducing the number of steps but no joy.

If I flatten the cluster to xml it is approx 24kB.

I have a tabbed control on the front panel to hold all the controls that go in the cluster.

I am using LCOD architecture for the program, i.e. everything in .lvlib and following an object oriented structure but I haven't followed this religiously.  The program I am doing is a proof of concept for a local hospital.  Not sure why it is 2MB in size of the disk.

The write to the database is 1.3MB in size and works fine.  Perhaps it is the tabbed control that is causing the issue but unfortunately, I need the tab control for presentation purposes.

I'm interested to know why 2MB would be seen as huge for a VI.

[Mark_Yedinak]

Have you considered using subpanels instead of a tab control. Load the appropriate page into the subpanel rather than use the tab control. Do you really need to have an "uber" cluster containing everything? This doesn't sound like very modular code.

If you do look into using subpanels I recommend you look at MGI's panel management toolkit.

[SeanJ]

Hi Mark,

I have been looking into subpanels for a similar purpose but never thought of it for this, great idea!

As deadlines will have it, I will have to live with what I've done for a while, it works fine when running. 

However, it'd be great if someone could explain why LabVIEW would struggle to manage a 2MB VI, especially given LabVIEW is using over 200MB of memory just with small VIs in memory now.  For comparison, Chrome  is currently using 1.5GB of memory because I have so many windows open.  Is it really a struggle for LabVIEW to work with a 2MB VI?