06-02-2022 02:50 PM - edited 06-02-2022 02:54 PM
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)
06-02-2022 03:04 PM
@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)
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.
06-02-2022 03:52 PM
I wonder is "separate compiled code" would have made a difference.
(I thought actually saved, but maybe I forgot.)
06-02-2022 05:04 PM - edited 06-02-2022 05:14 PM
@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)