JKISoftware/JKI-SMO-Templates

Remove unnecessary DVR to Ref calls for template VIs

Opened this issue · 1 comments

Is your feature request related to a problem? Please describe.
Our code review process aims to remove dead code or unnecessary function calls, and there's a lot of that in the SMO template methods. Most of our library code is SMO based and so when it comes time for code reviews we have to do some pretty redundant modification to these VIs.

Describe the solution you'd like
It would be great if the template VIs for all by-reference SMOs were refactored to use DVRs and more efficiently.

There is no need to operate on the Ref in-place, because it is a reference, so the In-place element structure is removed. Then, since we are operating on the DVR in an in-place element structure, there is no need to cast the DVR back to a reference, since the data has been updated in-place. This simplifies both the read and write accessors and allows for parallel reads of private data (if desired).

Additionally, the class data is never modified, so the wire can be passed straight through, simplifying wiring in the error structure.

Screenshots for details:

CreatePrivateEvents.vi
Before:
image

After:
image

SMO.BasicByRef.GetPrivateEvents.vi
Before:
image

After:
image

Describe alternatives you've considered
Manually editing all templates on my local machine is an option, but in a group of developers that means we end up with different templates, which defeats the point of templates. Of course, now we mark all of this up during our code review process, which tends to use a bit more time than we'd like.

Additional context
We have ~12 SMOs that are by ref and removing this manual work would be great. I'm not sure of any performance gains, but any time you remove code, I'm sure it gets a little bit faster, right?

@nathan-murphy , I checked into the SMO editor code to see if there was a way for you to be able to override with a plugin template, but there is currently none. I also tried to make a modification that would not break the editor in the template VIs. That also failed. (The editor is expressly trying to find the IPE+Unbundler/Bundler combination to act on the template, so it is not really scalable...)

The Editor code is not yet released as an open source project.
@jimkring Is this in the cards?