-
Notifications
You must be signed in to change notification settings - Fork 594
Fix wrong key type in LocalScheduler.addContainers #1426
Conversation
@billonahill @ashvina @avflor - can you please look at this change? |
33d7a8f
to
5ff3f23
Compare
for (PackingPlan.ContainerPlan container : containers) { | ||
if (processToContainer.containsKey(container.getId())) { | ||
if (containerIds.contains(container.getId())) { |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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)
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@billonahill Updated.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
.
LGTM 👍 |
5ff3f23
to
1b9d8af
Compare
👍 once CI passes. Thanks! |
The key type of
processToContainer
isProcess
,addContainers
should use its values to check the container id instead.