LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Shift Register Not Working Properly

Solved!
Go to solution

Your "inside" solution speeds up significantly if we don't connect the coerced output, i.e. conditionally indexing on the original array instead.

 

(It also gains slightly with parallelization on my 8 core Ryzen PC but it is definitely not worth stealing cores from other things that want them, just for some minor gain while adding more overhead)

 

Interesting...

 

(for some reason, I no longer see the extreme slowdown if "F" is rare. Not sure what else changed)

 

altenbach_0-1654198417415.png

 

0 Kudos
Message 11 of 14
(400 Views)

@altenbach wrote:

Your "inside" solution speeds up significantly if we don't connect the coerced output, i.e. conditionally indexing on the original array instead.

 

(It also gains slightly with parallelization on my 8 core Ryzen PC but it is definitely not worth stealing cores from other things that want them, just for some minor gain while adding more overhead)

 

Interesting...

 

(for some reason, I no longer see the extreme slowdown if "F" is rare. Not sure what else changed)

 

altenbach_0-1654198417415.png

 


I noted that too, until I forced a save and closed the inlined subvi.  A caller of inlined code really hates unsaved changes of the callee.  I had a "Jesus" moment a long time ago and don't even think about it much anymore, I just save.


"Should be" isn't "Is" -Jay
Message 12 of 14
(394 Views)

I wonder is "separate compiled code" would have made a difference.

 

(I thought actually saved, but maybe I forgot.)

0 Kudos
Message 13 of 14
(387 Views)

@altenbach wrote:

I wonder is "separate compiled code" would have made a difference.

 

(I thought actually saved, but maybe I forgot.)


Separate compiled is not set on this machine for 2021 (currently not working with others.)

 

Saving the subvi does not change the slowdown with unsaved changes but closing the vi and saving the caller DOES.  it could be that clearing the undo stack does this since getting rid of the dirty dot with undo does not effect redo but closing clears redo.

 

My habit is to save and close callees before running unless actively debugging subvis.  With larger projects with inherited vis I've even had to reduce the 99 step undo stack default to 9 or so to find very deep bugs. There is always SCC and snips in my working document describing where I'm seeing what when the bugs are out in swarms.  (one of the reasons I don't write bugs. They can be a real pain when they infest a project) 


"Should be" isn't "Is" -Jay
0 Kudos
Message 14 of 14
(378 Views)