Only `m` instants in this simulation matter: the seconds when a task arrives, plus the seconds when a stuck queue finally gets a server back. Everything between those is dead time, so the clock should jump, not tick. That is the whole reason I keep two heaps instead of one array of servers. The idle ones are ordered by `{weight, index}`, the working ones by `{free_at, weight, index}`. At second `j` I drain every server whose `free_at` has already passed into the idle heap and take its cheapest element. The instinct I rejected was scanning the server array for the lightest free machine at each task. With `n` and `m` both up to `2·10^5` that is 4·10^10 comparisons, and no amount of early exit saves it. The other dead end is advancing the clock second by second: a single server can be busy until second 4·10^10, so the time axis is not something you can walk. ## Clock that never goes back `t = max(t, j)` is the line that makes the whole thing correct. A task enters the queue at second `j`, but if the previous task had to wait until second 97, then tasks 1 through 97 are already sitting in the queue and get handed out at 97 in arrival order. The clock is monotone, so one pass is enough. When the idle heap is empty I move `t` straight to `get<0>(busy.top())` — the first release — and drain again. ## Worked example `servers = [3,3,2]`, `tasks = [1,2,3,2,1,2]`. - `t=0`: idle `{(2,2),(3,0),(3,1)}`, cheapest is weight 2 → server 2, free at 1. - `t=1`: server 2 comes back and is still the cheapest → server 2 again, free at 3. - `t=2`: nothing released yet, idle is `{(3,0),(3,1)}`, tie on weight 3 broken by index → server 0. - `t=3`: server 2 returns → server 2, free at 5. - `t=4`: only server 1 left → server 1. - `t=5`: all three return, weight 2 wins → server 2. Result `[2,2,0,2,1,2]`. The tie at `t=2` is where a `pair` pays off: lexicographic ordering on `{weight, index}` is exactly the rule the statement describes, so there is no custom comparator to get wrong. ## Complexity - **Time** O((n + m) log n) — every server enters each heap at most once per task it takes. - **Space** O(n) — the two heaps together hold exactly `n` servers. ## Code (C++) ```cpp class Solution { public: vector assignTasks(vector& servers, vector& tasks) { int n = servers.size(), m = tasks.size(); using Free = pair; // {weight, index} using Busy = tuple; // {free_at, weight, index} priority_queue, greater> idle; priority_queue, greater> busy; for (int i = 0; i < n; ++i) idle.push({servers[i], i}); auto release = [&](long long now) { while (!busy.empty() && get<0>(busy.top()) <= now) { auto [at, w, idx] = busy.top(); busy.pop(); idle.push({w, idx}); } }; vector ans(m); long long t = 0; for (int j = 0; j < m; ++j) { t = max(t, (long long)j); // task j shows up at second j, but we may already be later release(t); if (idle.empty()) { t = get<0>(busy.top()); // nothing free: skip straight to the first release release(t); } auto [w, idx] = idle.top(); idle.pop(); ans[j] = idx; busy.push({t + tasks[j], w, idx}); } return ans; } }; ``` ## One note The busy heap keys on `long long`, and that is not defensive padding. One server with `m = 2·10^5` tasks of 2·10^5 seconds each finishes at 4·10^10, which overflows a 32-bit `int` by a factor of twenty. The answer array only ever holds indices, so the overflow would not show up as a wrong index in the small samples — it shows up as a negative `free_at` on a large test, which means a busy server reads as free and the assignment silently diverges. Nothing in the problem's output type warns you about this. Two things I take away. First: when a simulation's state is "who is free, who is busy", two heaps split by that state beat one sorted structure, because a server only ever moves one way at a time. Second: in event-driven simulations the clock is a separate quantity from the loop index, and the overflow lives in the clock, not in the data you were given.