LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

IDE not responding, rewire a wire takes 30+ secs to take effect?

When I have to change configure Discrete Delay or even rewire a wire, the IDE takes about 30 secs to responding.

jiangliang_0-1610617074341.png

 

Also, if I open Windows resource manager I can see it shows LabVIEW is waiting for network IO? I can't get the point why LabVIEW is waiting for network IO? or maybe this is not relevant?

jiangliang_1-1610617336949.png

 

The VI is kind of complex, it is a custom FIR filter, and I prefer to have this function in one VI.

 

I also tried to close VI and reopen it, restart LabVIEW, restart PC, none of them really helps, maybe the first 3 or 5 wires respond better (also takes 5+ secs), soon the overall performance drops to unbearable.

 

0 Kudos
Message 1 of 14
(1,500 Views)

Are you connected to any target on the network?

 

Or is your compile cache in your user account folder on a server drive?

0 Kudos
Message 2 of 14
(1,475 Views)

Not that I know.

I was editing the VI in local SSD, also, simply wiring a wire shouldn't trigger save operation, I suppose?

0 Kudos
Message 3 of 14
(1,468 Views)

Wiring a wire will cause a recompile.  Remember, LV compiles on the fly.  I have had pretty dramatic pauses when my front panel has a lot of data in it.  Sometimes it even gets tough to move stuff because of that.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 14
(1,440 Views)

@billko wrote:

Wiring a wire will cause a recompile.  Remember, LV compiles on the fly.  I have had pretty dramatic pauses when my front panel has a lot of data in it.  Sometimes it even gets tough to move stuff because of that.


Precisely because of this "recompile-on-the-fly" means that just installing LV or having your VIs on an SSD will not help as LV automatically places your compile cache in your profile folder which, if it's not also on an SSD, will seriously slow things down.

 

Intaris_0-1610634133391.png

Here in the options of LabVIEW, you can move the default data directory (Which is where LV puts your compile cache I think) to another drive.

Message 5 of 14
(1,423 Views)

Thanks, I will give a try, and will it help if I set this data folder to a ramdisk?

---------------------------------------------------------------------------------------------------

I checked the data folder, seems there are lots of files, I only changed the temp folder to a ramdisk hope it will help...

 

And I have two SSD, no HDD, and 64GRAM on a 8 core i7, which should be far from enough for a simple wiring...

 

Also, I already set on the fly recompile level to 1, which doesn't seems to help.

 

 

 

0 Kudos
Message 6 of 14
(1,417 Views)

Oh no, not a ramdisk. That would be catastrophic. My understanding is that a ramdisk is not persistent..... My knowledge may come from previous decades (centuries if we want to be pedantic 👴), but I presume this is still the case?

 

Sure, once things are compiled, things would run nice and fast. But it would need to re-create everything every time you reboot, which will end up costing you huge amounts of time.

 

Make sure your default data folder is persistent.

 

OK; I see now that you don't have any HDDs, so that step I mentioned should be completely unneccessary. You should be fine with the directories at their default locations.

0 Kudos
Message 7 of 14
(1,411 Views)

Nothing really changes after I set the temp dir to ramdisk. still very slow when I rewire the wire.

 

Can anyone give me some suggestions?

0 Kudos
Message 8 of 14
(1,381 Views)

If you do a "save all", does that maybe help?

 

Do you have classes with a lot of version history?

 

Have you excluded LabVIEW folders (DefaultData, your Code) from any anti-virus on your PC?

0 Kudos
Message 9 of 14
(1,377 Views)

How much memory is being taken up by this VI?  (Even if the VI itself isn't very complex, if you have arrays holding lots of data as either constants or front panel objects, it might take up quite a bit of memory.)

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 10 of 14
(1,364 Views)