[
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)
