Change:
numPDBViolatingPods := victims.numPDBViolations if numPDBViolatingPods < minNumPDBViolatingPods { minNumPDBViolatingPods = numPDBViolatingPods <del> minPDBViolatingNodes = nil </del> <ins> minNodes1 = nil lenNodes1 = 0 </ins> } if numPDBViolatingPods == minNumPDBViolatingPods { <del> minPDBViolatingNodes = append(minPDBViolatingNodes, node) </del> <ins> minNodes1 = append(minNodes1, node) lenNodes1++ </ins> } } <del> if len(minPDBViolatingNodes) == 1 { return minPDBViolatingNodes[0] </del> <ins> if lenNodes1 == 1 { return minNodes1[0] </ins> } // There are more than one node with minimum number PDB violating pods. Find // the one with minimum highest priority victim. minHighestPriority := int32(math.MaxInt32) <del> var minPriorityNodes []*v1.Node for _, node := range minPDBViolatingNodes { </del> <ins> var minNodes2 = make([]*v1.Node, lenNodes1) lenNodes2 := 0 for i := 0; i < lenNodes1; i++ { node := minNodes1[i] </ins> victims := nodesToVictims[node] // highestPodPriority is the highest priority among the victims on this node. highestPodPriority := util.GetPodPriority(victims.pods[0]) if highestPodPriority < minHighestPriority { minHighestPriority = highestPodPriority <del> minPriorityNodes = nil </del> <ins> lenNodes2 = 0 </ins> } if highestPodPriority == minHighestPriority { <del> minPriorityNodes = append(minPriorityNodes, node) </del> <ins> minNodes2[lenNodes2] = node lenNodes2++ </ins> } } <del> if len(minPriorityNodes) == 1 { return minPriorityNodes[0] </del> <ins> if lenNodes2 == 1 { return minNodes2[0] </ins> } // There are a few nodes with minimum highest priority victim. Find the // smallest sum of priorities. minSumPriorities := int64(math.MaxInt64) <del> var minSumPriorityNodes []*v1.Node for _, node := range minPriorityNodes { </del> <ins> lenNodes1 = 0 for i := 0; i < lenNodes2; i++ { </ins> var sumPriorities int64 <ins> node := minNodes2[i] </ins> for _, pod := range nodesToVictims[node].pods { // We add MaxInt32+1 to all priorities to make all of them >= 0. This is // needed so that a node with a few pods with negative priority is not

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Fix the following : The basic logic in of using the is continuing reducing the nodes slices through , , and . It needs 4 slices to do this. This is my thought to reuse the slices: Use 2 nodes slices, such as , The reducing process becomes: -Clear -Clear - please give some suggestion, thanks :smile:
/sig scheduling
The challenge is that clearing a slice and reusing it still needs GC clean up, so it may not be effective. The size of slices shrink as we proceed through the function. So, having two slices and over-writing the elements in them can help reduce GC time, but this approach needs some additional checks to ensure we are not using stale elements.
To avoid clearing the slices, this is my thought: Declare to indicate the actual length of the 2 node slices, instead of . Appending a node to a node slice will add 1 to . Clearing a node slice will set to 0. WDYT
Yes, I can't think of any better solution either, but remember that you should append only to the slice in the first for loop of the function. The second slice should be initialized with the same number of elements as the slice used in the first for loop. Setting elements of the slices should be done by indexing them (not by append) in the second, third, and forth loop.
OK, I will submit a PR to implement it.