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.
return executors.contains(frameworkId) &&

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.


> 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

Reply via email to