Restore LVMessageEfficient functionality after gRPC upgrade to v1.62.0

[Sacheta-NI]

As part of the upgrade to gRPC v1.62.0 (from v1.44), the LVMessageEfficient feature was temporarily disabled due to a breaking change in the updated Protobuf library. Specifically, RepeatedField no longer supports the char type, which was used in the LVMessageEfficient class. The system currently falls back to using the LVMessage class as a workaround.

This issue tracks the work required to:

Refactor LVMessageEfficient to align with the updated Protobuf library.

Re-enable the LVMessageEfficient feature through the feature toggle mechanism.

AB#3111300

[jplotzke]

Hi,
Can you elaborate on any efficiency implications that are caused by disabling LVMessageEfficient? Would you expect that updating to grpc-labview v1.5.0.1 (which includes grpc v1.62) would operate less efficiently as previous versions due to falling back to LVMessage? Or am I reading too much into the name of this class? :)

[jasonmreding]

Use of that message class only applies (or did apply) to unary calls made from the client side. It primarily optimizes serialization of request/response messages containing repeated fields, nested message fields, or combinations of the two by avoiding intermediary copies of the data that are incurred with the fallback message type. So yes, it is less efficient in those cases although I don't have any meaningful performance numbers that characterize it any better than that. I don't really expect the difference to be noticeable unless you are passing somewhat large arrays of data in the request/response message.