[ https://issues.apache.org/jira/browse/MESOS-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042695#comment-16042695 ]
Dmitry Zhuk commented on MESOS-6972: ------------------------------------ [~bmahler], what do you think about taking a different approach: since in many cases {{RepeatedPtrField}} needs to be converted to {{vector}} anyway, e.g. to pass to internal data structures, we can instead {{Swap}} values from {{RepeatedPtrField}} to {{vector}}. This does not add too much overhead compared to {{RepeatedPtrField}}. Currently a handler can be installed by calling something like this: {code} template <typename M, typename P1, typename P1C> void install( void (T::*method)(const process::UPID&, P1C), P1 (M::*param1)() const); {code} {{P1 (M::*param1)() const}} is an issue here, as it prevents from swapping from returned const {{RepeatedPtrField}}. We can either remove {{const}} from {{param1}} and update code to use {{mutable_*}} versions to access message properties, or keep it as is, and do {{const_cast}} as a part of conversion. The latter however, somewhat depends on protobuf internals and could break for non-primitive defaults. I've already tested this change ({{const_cast}} variant), and results look promising for hotspots like {{reregisterSlave}}. > Improve performance of protobuf message passing by removing RepeatedPtrField > to vector conversion. > -------------------------------------------------------------------------------------------------- > > Key: MESOS-6972 > URL: https://issues.apache.org/jira/browse/MESOS-6972 > Project: Mesos > Issue Type: Improvement > Reporter: Benjamin Mahler > Labels: tech-debt > > Currently, all protobuf message handlers must take a {{vector}} for repeated > fields, rather than a {{RepeatedPtrField}}. > This requires that a copy be performed of the repeated field's entries (see > [here|https://github.com/apache/mesos/blob/9228ebc239dac42825390bebc72053dbf3ae7b09/3rdparty/libprocess/include/process/protobuf.hpp#L78-L87]), > which can be very expensive in some cases. We should avoid requiring this > expense on the callers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)