01-09-2019 06:52 AM
I am using LabVIEW 2017 Professional.
I counted 16 seconds to save my VI when I disabled the close front panel section in it (minor change).
VI is 1.87MB in size.
As you can see above, LabVIEW is using 33.3% CPU and there is nearly twice that free for use. There is 16GB of RAM so barely affecting that.
The machine is a bit old but specs are not bad:
Intel Core i5 3570K @ 3.40GHz 55 °C 16.0GB Dual-Channel DDR3 @ 672MHz (9-9-9-24) Gigabyte Technology Co. Ltd. Z77X-UD3H (Intel Core i5-3570K CPU @ 3.40GHz) 28 °C 2047MB NVIDIA GeForce GTX 660 Ti (ZOTAC International)
Any ideas, why is takes 16 seconds to save the VI. FWIW, this is really impacting my work rate.
Thanks,
Seán
01-09-2019 07:15 AM
01-09-2019 11:04 AM
I'm suspecting the VI has some large amount of data stored as either a constant or as a default value. A "super-cluster" with a lot of numeric elements to it will do the same thing, regardless of default value settings because LabVIEW because there is already a default value - zero - in numeric controls.
01-09-2019 11:42 AM
How is your disk space?
If the space is low and file is large it will be scattered all over the disk filling in little holes. In between each sector written there could be a seek that slows things down due to disk latency.
So make some room on the disk and defragment it... perhaps?
Ben
01-09-2019 03:19 PM
I agree with the others that that is a large VI and could have something to do with it. And while this is not always an option, LabVIEW 2018 at least for me (especially SP1 F1) caused saving to be much faster, particularly when switching between targets or instances.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
01-10-2019 01:12 AM
On the other side, I have some vi's of similar size, but you would barely notice the saving time (slightly better but comparable machine).
There must be something special about your vi.
01-10-2019 01:23 AM
I've had similar things happen where it could take minutes to save a VI. If you find some answer i'd be interested, but my best guess is some high dependency/linkage situation that'll cause it to research/recompile.
/Y
01-10-2019 04:45 AM
Hi All,
Thanks for all your suggestions.
In answer to Ben there is 1.27GB free on the LabVIEW program drive partition with 550GB in use.
The cluster when saved as an INI file occupies 10KB. The super cluster is split into separate clusters that are displayed in tabs.
Any help appreciated as basically I am a ctrl + s person. I always save changes and waiting 16s waiting for a minor change to save is not fun!
01-10-2019 07:28 AM
I am a "ctrl-s"-er as well.
I do not know if we can rule out the disk space since that is less than %1 free. If that space is the total of 1M of 1K sectors, writing that file could involve seeks to 1000 different locations. Throw in you disk latency numbers...
If you start a defrag it used to show just how fragmented the disk is before it started. I have not done one myself in a good long time.
Another thought could be X-Controls. They have their own save methods if I recall. I admit I may be wrong on that point since it has been along time since I messed with them as well.
So I am just sharing thoughts for you to consider. If you figure it out, let us know so we can help others.
Take care,
Ben
01-10-2019 07:33 AM
Copy your VI somewhere safe. If it takes the same amount of time to save, do the following to your copy (if not, work on the original.):
Delete the super cluster (and all its offshoots) then save. There's a fair probability that your VI size goes way down and it saves almost immediately.
I think the issue comes with having lots of high-memory stuff on your front panel. Usually that comes from saving a huge array as a default value, but if you have enough single elements, it can occasionally happen, too.
You're getting mostly wild guesses because no one has seen your code yet. (Probably you can't share it with us, and it does no good to send a stripped-down version that you can share, so kind of understood in this case.) But if you can share the code, it would help a lot.