Skip to content
This repository has been archived by the owner on Mar 3, 2023. It is now read-only.

Fix wrong key type in LocalScheduler.addContainers #1426

Merged
merged 1 commit into from
Sep 27, 2016

Conversation

windie
Copy link
Contributor

@windie windie commented Sep 25, 2016

The key type of processToContainer is Process, addContainers should use its values to check the container id instead.

@kramasamy
Copy link
Contributor

@billonahill @ashvina @avflor - can you please look at this change?

for (PackingPlan.ContainerPlan container : containers) {
if (processToContainer.containsKey(container.getId())) {
if (containerIds.contains(container.getId())) {
Copy link
Contributor

@billonahill billonahill Sep 26, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch! Instead of maintaining another Set could you just check processToContainer.values().containsKey(container.getId())? That guarantees that we're always in sync with what startExecutor has started, since it updates processToContainer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@billonahill The time complexity of my current approach is just O(# existing containers) + O(# the added containers). But if using processToContainer.values().contains(container.getId()), the time complexity will become O(# existing containers) * O(# the added containers).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a great observation @windie. If we were running production topologies with this class that added many containers I'd agree that this is a concern. In this case though, this is a local scheduler used for local development which we wouldn't expect to need to add more than max 2-3 containers to ever. For that reason I think think we should favor simplicity and code readability over the performance aspect.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@billonahill Updated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@windie circling back on this since I realized that HashMap.values() returns the same view into the hashmap when called repeatedly, so the optimization question is moot. Calling remove on the map removes the entry and updates the backing values set.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@billonahill values is not a set. Did you mean keySet?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, values is a Collection which is what I was in fact referring to. Calling map.values().contains(foo) repeatedly as we add containers will not have O(# existing containers) * O(# the added containers) complexity, because map.values() does not need to be reconstructed for every value added, which is what I thought you were implying. The same backing collection gets used in the map impl, as new items are inserted so performance is the same as if we manage our own collections of values

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry that I was not clear. I meant the contains method is O(# existing containers).

@billonahill billonahill added this to the 0.14.4 milestone Sep 26, 2016
@ashvina
Copy link
Contributor

ashvina commented Sep 26, 2016

LGTM 👍

@billonahill
Copy link
Contributor

👍 once CI passes. Thanks!

@billonahill billonahill merged commit 3b22514 into apache:master Sep 27, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants