Anyone else finding VIMs to be painfulllly slow to edit in 2023 Q3?

[_carl]

Subject line pretty much says it all.

I rely heavily on VIMs as they're extremely powerful (despite their flaws).  After a migration to 2023 Q3, I'm finding some VIMs to be extremely painful to edit.  As in, I'll have to wait over a minute for the mouse cursor to update appropriately.  It can take 5 or more minutes to perform the most basic of operations.  And sometimes I end up having to declare LabVIEW hung, and killing the process.

This seems to happen if the VIM has a broken run arrow -- performance gets much better the moment the run arrow is unbroken.

Suspect it's tied to VIMs that are either nested or called in many places, as LabVIEW's likely updating all caller code with every mouse click.

Workarounds I can think of include:

- Not using VIMs (not an option)

- Having VIMs in their own library that I open independently of other code (not really realistic or efficient)

- Never edit my VIMs.  Preferred solution, but also not realistic.

- Changing VIMs to non-inlined VIs temporarily.  Annoying and inefficient, and must be done before breaking the VI, which is near-impossible to remember to do.

- Reverting to a previous version of LabVIEW.

If I'm using VIMs, I don't think any of the above are realistic long-term solutions (except for reverting a  previous version of LabVIEW) -- looking for other suggestions (or better yet, a bug fix!).

[santo_13]

Do you have any simple VIM that can help reproduce your observation?

[JÞB]

Wild suggestion: If you have a reproducible set of steps try this hack.

Temporarily adjust the default Configuration settings for Maximum Undo Steps per VI from 99 to 9. Rational: with heavily nested vims with callers in memory something might be junking up the undo stack.

[_carl]

I don't have a sharable snippet of code at the moment (or the time to build one up), but will post later if I'm able to reproduce with something simple.

JÞB, that is a wild suggestion. And I'll try it next time I find myself battling this situation and report back!

I did find that by closing LabVIEW, and then opening only the VIM that was causing me issues, I was able to quickly make changes to it.  But...with large projects...that's an unproductive workflow.

[_carl]

Thought I'd follow up on this:

Issue appeared to be that I had a VIM in a VIM with some class data -- and this did not sit well with LabVIEW.  In addition to being slow to edit, this VIM eventually corrupted my project and proved to be difficult to track down.  (Corrupted in the sense that LabVIEW couldn't back-save to previous versions of LabVIEW because of this one file, and would regularly crash).  Redoing things to remove the VIM-in-VIM (by duplicating some code, unfortunately), things worked great.  Corruption removed, slow performance gone.  Issue did not appear to be specific to 2023 Q3, as 2023 Q1 also had trouble with this VIM -- although the user experience did appear to handle things more gracefully in Q1.  (Q3 would get stuck in more endless compile loops, took longer to open things, and seemed more likely to crash).

[BertMcMahan]

I have heard rumors that VIM's in VIM's, classes in VIM's, and Xnodes in VIM's are to be avoided if possible.

I recently had a VIM in a VIM problem a couple weeks back that was apparently caused by a VIM inside a TSS inside a VIM. Removing the internal TSS with VIM in it fixed my corrupted VI issue. I still have the VIM in a VIM, but apparently a VIM in a TSS in a VIM is risky.