[
https://issues.apache.org/jira/browse/MESOS-9948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933393#comment-16933393
]
Benjamin Bannier commented on MESOS-9948:
-----------------------------------------
Looking at the trace more carefully the issue here _is not_ with inefficient
lookups, but due to the creation of temporaries. The user likely has frameworks
with lots of executors and by accessing the framework's executors with
{{Option::get}} we force creation of a temporary copying the whole executor
map, even though a reference would work just fine.
{code}
return executors.contains(frameworkId) &&
executors.get(frameworkId)->contains(executorId);
{code}
This seems not seem to be an isolated instance of this misuse, but only one
with particularly inefficient case. We should consider whether providing
{{hashmap::get}} at all is useful given its potential for misuse.
Reviews:
https://reviews.apache.org/r/71519/
https://reviews.apache.org/r/71520/
> master::Slave::hasExecutor occupies 37% of a 150 second perf sample from a
> user.
> --------------------------------------------------------------------------------
>
> Key: MESOS-9948
> URL: https://issues.apache.org/jira/browse/MESOS-9948
> Project: Mesos
> Issue Type: Improvement
> Components: master
> Reporter: Benjamin Mahler
> Assignee: Benjamin Bannier
> Priority: Major
> Labels: foundations, performance
> Attachments: long-fei-enable-debug-slow-master.gz
>
>
> If you drop the attached perf stacks into flamescope, you can see that
> mesos::internal::master::Slave::hasExecutor occupies 37% of the overall
> samples!
> This function does 3 hashmap lookups, 1 can be eliminated for a quick win.
> However, the larger improvement here will come from eliminating many of the
> calls to this function.
> This was reported by [~carlone].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
