Every query asks for servers that stayed quiet, but it is far easier to count the ones that spoke: the answer is `n` minus the number of distinct server ids with a log inside `[queries[i] - x, queries[i]]`. All windows have the same width, so if I walk the queries in increasing order, the window only ever slides right — each log event enters the window once and leaves once, forever. The instinct I dropped was answering each query where it stands: scan all logs, collect the ids that fall in range, subtract. With `10^5` logs and `10^5` queries that is `10^10` comparisons, and it also throws away the fact that consecutive windows overlap almost entirely. Sorting both sides turns those overlaps into reuse. So: sort logs by time, sort the query *indices* by query value, and run two pointers over the log array while a `cnt` array per server id tracks how many of its events sit in the current window. A separate `active` counter changes only when some `cnt[id]` crosses the 0/1 boundary, which is what makes "distinct ids in the window" an O(1) read. ## Worked example Take `n = 3`, `logs = [[1,3],[2,6],[1,5]]`, `x = 5`, `queries = [10,11]`. Logs sorted by time: `[1,3]`, `[1,5]`, `[2,6]`. Queries are already increasing. For `queries[0] = 10` the window is `[5,10]`. The right pointer admits all three events (times 3, 5, 6 are all `<= 10`), giving `cnt[1] = 2`, `cnt[2] = 1`, `active = 2`. The left pointer then evicts events with time `< 5`, so `[1,3]` drops out and `cnt[1]` falls to 1 — still nonzero, so `active` stays 2. Answer: `3 - 2 = 1`, server 3. For `queries[1] = 11` the window is `[6,11]`. Nothing new to admit. The left pointer evicts time `< 6`, so `[1,5]` leaves and `cnt[1]` hits 0, dropping `active` to 1. Answer: `3 - 1 = 2`, servers 1 and 3. Result `[1,2]`, which matches. ## Complexity - Time O(m log m + q log q) — the two sorts dominate, since each pointer crosses the log array exactly once across all queries. - Space O(n + q) — one counter per server id plus the query permutation and the output. ## Code (C++) ```cpp class Solution { public: vector countServers(int n, vector>& logs, int x, vector& queries) { sort(logs.begin(), logs.end(), [](const vector& a, const vector& b) { return a[1] < b[1]; }); int q = queries.size(); vector order(q); for (int i = 0; i < q; ++i) order[i] = i; sort(order.begin(), order.end(), [&](int a, int b) { return queries[a] < queries[b]; }); vector cnt(n + 1, 0); vector res(q); int lo = 0, hi = 0, active = 0; for (int idx : order) { int r = queries[idx]; int l = r - x; while (hi < (int)logs.size() && logs[hi][1] <= r) { if (cnt[logs[hi][0]]++ == 0) ++active; ++hi; } while (lo < hi && logs[lo][1] < l) { if (--cnt[logs[lo][0]] == 0) --active; ++lo; } res[idx] = n - active; } return res; } }; ``` ## One note The two pointer conditions are deliberately asymmetric: admit while `logs[hi][1] <= r`, evict while `logs[lo][1] < l`. Both ends of `[queries[i] - x, queries[i]]` are inclusive, so writing the eviction as `<= l` throws out the event sitting exactly on the left edge and inflates the "quiet" count. In my worked example that single character would have reported 2 instead of 1 for the first query. It is the kind of off-by-one that passes the samples when `x` happens to be large and fails deep in a hidden test. Two things worth carrying off: when queries are offline and the window width is fixed, sort an index permutation rather than the queries themselves — the answers still have to land in the caller's original order, and `res[idx]` is the only place that order survives. And a frequency array plus a single `active` counter beats a hash set of live ids here, because server ids are bounded by `n`, so `cnt[id]++ == 0` and `--cnt[id] == 0` are the entire multiset-to-set bookkeeping.