1366. Rank Teams by Votes

Wed, 19 Aug 2026 18:52:21 +0000

Problem
In a special ranking system, each voter gives a rank from highest to lowest to all teams participating in the competition.

The ordering of teams is decided by who received the most position-one votes. If two or more teams tie in the first position, we consider the second position to resolve the conflict, if they tie again, we continue this process until the ties are resolved. If two or more teams are still tied after considering all positions, we rank them alphabetically based on their team letter.

You are given an array of strings votes which is the votes of all voters in the ranking systems. Sort all teams according to the ranking system described above.

Return a string of all teams sorted by the ranking system.

Example 1:

Input: votes = ["ABC","ACB","ABC","ACB","ACB"]
Output: "ACB"
Explanation:
Team A was ranked first place by 5 voters. No other team was voted as first place, so team A is the first team.
Team B was ranked second by 2 voters and ranked third by 3 voters.
Team C was ranked second by 3 voters and ranked third by 2 voters.
As most of the voters ranked C second, team C is the second team, and team B is the third.
Example 2:

Input: votes = ["WXYZ","XYZW"]
Output: "XWYZ"
Explanation:
X is the winner due to the tie-breaking rule. X has the same votes as W for the first position, but X has one vote in the second position, while W does not have any votes in the second position.
Example 3:

Input: votes = ["ZMNAGUEDSJYLBOPHRQICWFXTVK"]
Output: "ZMNAGUEDSJYLBOPHRQICWFXTVK"
Explanation: Only one voter, so their votes are used for the ranking.

Constraints:

1 <= votes.length <= 1000
1 <= votes[i].length <= 26
votes[i].length == votes[j].length for 0 <= i, j < votes.length.
votes[i][j] is an English uppercase letter.
All characters of votes[i] are unique.
All the characters that occur in votes[0] also occur in votes[j] where 1 <= j < votes.length.

Discussion
This problem can be solved using 2 data structures- a hashmap and a heap. We use the map to store the votes by each judge and the heap to sort the teams. We create a comparator to sort the teams and initialize the heap using it.
We then traverse the votes array to calculate the votes and create the map.Once this is done we add the keys of the map which are the teams to the heap and pull the elements off one by one to get the final string.

Solution

Java

class Solution {
    public String rankTeams(String[] votes) {
      HashMap<Character,int[]>map=new  HashMap<>();
      String answer="";
      for(int i=0;i<votes.length;i++){
       String vote=votes[i];
       for(int j=0;j<vote.length();j++){
        char team=vote.charAt(j);
        if(!map.containsKey(team)){
         int [] counts= new int[vote.length()];
         counts[j]++;
         map.put(team,counts);
        }else{
          int [] counts =map.get(team);
          counts[j]++;
          map.replace(team,counts);
        }
       } 
      }
      PriorityQueue<Character> pq = new PriorityQueue<>((a, b) -> {
        int[] va = map.get(a);
        int[] vb = map.get(b);
        for (int i = 0; i < va.length; i++) {
            if (va[i] != vb[i]) {
            return Integer.compare(vb[i], va[i]);
             }
        }
        return Character.compare(a, b);
      });  
      for (char team : map.keySet()) pq.offer(team);
      while(!pq.isEmpty()){
       char ch=pq.poll();
       answer+=ch; 
      }
      return answer;
    }
}

Is Your Game Choking on GC Allocations?

Fri, 03 Jul 2026 21:43:02 +0000

Is Your Game Choking on GC Allocations? A Guide to Zero-Allocation Data Structures

Introduction

You’ve optimized your shaders, painstakingly batched draw calls, and even dipped your toes into Unity’s Burst Compiler and C# Job System. Yet, your game still experiences inexplicable hitches and stutters, particularly during intense moments. The silent assassin in many Unity games isn’t the GPU struggling with pixels, but the Garbage Collector (GC) reclaiming memory from incessant, hidden allocations. Specifically, insidious GC.Alloc calls, often for temporary class-based data structures, can disrupt your carefully crafted frame budget, leading to frustrating performance spikes.

This tutorial will illuminate this common pitfall and provide a robust architectural solution: embracing struct types combined with Span<T> for transient data. By understanding and applying these principles, you can virtually eliminate many GC.Alloc calls from your high-frequency game logic, leading to buttery-smooth frame rates and a fundamentally cleaner, faster codebase.

The Culprit: Unnecessary Class Allocations

The core problem stems from the fundamental difference between class and struct in C#. A class is a reference type, always allocated on the managed heap. When you create an instance of a class using new, memory is allocated on the heap, and a reference to that memory is returned. When that instance is no longer reachable, it becomes garbage, waiting for the GC to collect it – an operation that can cause noticeable stalls.

Consider a common scenario: processing temporary query results or calculating scores for nearby entities every frame. If you use a class to represent these temporary data points and store them in a List<T>, you’re incurring a double hit:

List<T> itself is a class, though often its internal array can be reused.
Each T instance (if T is a class) added to the list is a separate heap allocation.

Let’s illustrate with a typical (and problematic) pattern for calculating and processing scores for nearby interactable objects:

// PROBLEM: Class-based data structure
public class InteractableScore
{
    public GameObject Target;
    public float Score;

    // Constructor or properties often implicitly lead to heap allocations
    public InteractableScore(GameObject target, float score)
    {
        Target = target;
        Score = score;
    }
}

public class ScoreCalculator : MonoBehaviour
{
    private List<InteractableScore> _currentScores = new List<InteractableScore>();

    void Update()
    {
        _currentScores.Clear(); // Clears references, but allocated objects are now garbage
        
        // Imagine GetNearbyInteractables() yields many results
        foreach (var interactable in GetNearbyInteractables()) 
        {
            float score = CalculateScore(interactable);
            _currentScores.Add(new InteractableScore(interactable, score)); // !!! EACH 'new' is a GC.Alloc !!!
        }

        ProcessScores(_currentScores); 
    }

    private IEnumerable<GameObject> GetNearbyInteractables() { /* ... implementation ... */ return new List<GameObject>(); }
    private float CalculateScore(GameObject obj) { /* ... implementation ... */ return 0f; }
    private void ProcessScores(List<InteractableScore> scores) { /* ... implementation ... */ }
}

In this Update loop, if GetNearbyInteractables() returns 10 objects, you’ve just made 10 new InteractableScore() heap allocations every single frame. Over time, this rapid allocation and deallocation will trigger frequent GC cycles, causing noticeable stutter.

The Solution: Embrace Structs and Span

The solution lies in leveraging value types (struct) and efficient memory slicing (Span<T>). A struct is a value type, meaning its instances are typically allocated directly on the stack (for local variables) or inline within its containing type (if part of an array or another object). When a struct is copied, its entire data is copied, not just a reference. This means no heap allocation for the struct itself, and thus, no GC pressure from its creation.

For temporary collections of struct data, we combine struct with a pre-allocated array and Span<T>. An array, even of structs, is a reference type allocated on the heap once. By pre-allocating an array large enough to hold your maximum expected temporary data, you perform a single heap allocation at startup. Then, you fill this array with struct instances. Since structs are value types, assigning them to array elements does not create new heap allocations for the struct data itself. Finally, Span<T> provides a lightweight, zero-allocation “view” into a portion of this array, allowing you to process only the relevant data without copying or allocating new collections.

Here’s the refactored, performance-optimized approach:

// SOLUTION: Struct-based data structure
public struct InteractableScoreData // It's a struct!
{
    public GameObject Target;
    public float Score;
}

public class ZeroAllocScoreCalculator : MonoBehaviour
{
    // Pre-allocate the buffer ONCE at startup. This is a single heap allocation.
    // Choose a size appropriate for your maximum expected interactables.
    private InteractableScoreData[] _scoreBuffer = new InteractableScoreData[50]; 

    void Update()
    {
        int currentScoreCount = 0; // Tracks how many valid scores we've added to the buffer
        
        foreach (var interactable in GetNearbyInteractables())
        {
            if (currentScoreCount < _scoreBuffer.Length) // Prevent out-of-bounds
            {
                float score = CalculateScore(interactable);
                // Assigning a struct to an array element does NOT allocate on the heap!
                _scoreBuffer[currentScoreCount] = new InteractableScoreData 
                { 
                    Target = interactable, 
                    Score = score 
                };
                currentScoreCount++;
            }
        }

        // Use Span<T> to create a zero-allocation view of the valid data in our buffer
        Span<InteractableScoreData> currentScores = _scoreBuffer.AsSpan(0, currentScoreCount);
        
        // Process the scores using the Span
        ProcessScores(currentScores); 
    }

    private IEnumerable<GameObject> GetNearbyInteractables() { /* ... implementation ... */ return new List<GameObject>(); }
    private float CalculateScore(GameObject obj) { /* ... implementation ... */ return 0f; }
    
    // Updated to accept Span<T>
    private void ProcessScores(Span<InteractableScoreData> scores) 
    { 
        foreach (ref readonly var scoreData in scores) // Using 'ref readonly' for even more efficiency
        {
            // Process scoreData directly from the buffer without copying
            Debug.Log($"Target: {scoreData.Target.name}, Score: {scoreData.Score}");
        }
    }
}

In this refined code, the _scoreBuffer is allocated only once when the MonoBehaviour starts. In Update, no new heap memory is allocated for InteractableScoreData instances. Instead, the struct values are directly assigned into pre-existing slots in the array. Span<T> then provides an incredibly efficient way to iterate over the valid portion of this array without any additional memory allocations.

This approach not only prevents GC spikes but also significantly improves cache locality. Because struct instances in an array are laid out contiguously in memory, the CPU can process them much faster, leveraging its cache more effectively – a critical win for data-oriented design.

Conclusion

Eliminating insidious GC.Alloc calls is paramount for achieving consistent, high frame rates in Unity. By consciously choosing struct over class for transient, high-frequency data and combining this with pre-allocated buffers viewed through Span<T>, you can drastically reduce GC pressure. This isn’t just about micro-optimizations; it’s about adopting a fundamentally cleaner and faster architectural pattern for your game logic. Start treating memory as a finite resource, and your game’s performance will thank you.