DOJ logoDOJ
Problems
Recently added problemsSaved problems
CategoriesDLCContestsGroupsTeamsBoard
Ranking
Solved Problem RankingStreak rankingDOJ Power ranking
Status
Call for TasksLoginRegister
DOJ logoDOJ

Community online judge with OI-style subtask scoring, Elo ratings, and Discord-backed certification.

Problems
ProblemsCategories
Community
ContestsRankingBoardNoticesHost an external contestGuide
Account
LoginRegisterJudge Status
Policy
Terms of ServiceDLC RulesPrivacyAPI documentationLanguage runtimesContest rank rewardsRating and performance
© 2026 DOJ
All rights reserved
Editorial

International OJ

Back to problem

Editorial

Computing completion times

Let FiF_iFi​ be the completion time of the last submission ever inserted into server iii. When a submission with judging time yyy is inserted into server iii at time ttt, its start and completion times are

start=max⁡(t,Fi),finish=max⁡(t,Fi)+y.\mathrm{start}=\max(t,F_i),\qquad \mathrm{finish}=\max(t,F_i)+y.start=max(t,Fi​),finish=

Then update FiF_iFi​ to the new completion time. Because each server processes its queue in FIFO order, the actual queue does not have to be stored.

Different servers work simultaneously, so submission-query order and completion order may differ. Store every completion event in a min-heap ordered by completion time. Before processing a query at time ttt, pop and apply every event whose completion time is at most ttt.

Completion times can become much larger than the input bound on ttt. Many submissions of judging time 10910^9109 can wait on one server, so completion times must be stored in 64-bit integers.

Per-problem ranking

The comparison key of a completed submission is

(judgeTime, finishTime, submissionOrder).(\mathrm{judgeTime},\ \mathrm{finishTime},\ \mathrm{submissionOrder}).(judgeTime, finishTime, submissionOrder).

Only the best 555 submissions of each problem are ever needed. For every problem, keep a sorted vector containing at most those 555 records. Insert a newly completed record, sort the vector, and remove the last record if the size becomes 666.

A record that has already fallen out of the best 555 can never return later, because inserting additional records cannot improve its relative position. Therefore each problem stores only O(1)O(1)O(1) records.

User ranking

For every user uuu, maintain:

  • CuC_uCu​: the current number of solved problems;
  • AuA_uAu​: the time at which the user achieved the current solved count.

The user-ranking key is

(−Cu, Au, nickname).(-C_u,\ A_u,\ \mathrm{nickname}).(−Cu​, Au​, nickname).

Store these keys in a std::set; iterating from the beginning gives the ranking order.

When a user solves a new problem for the first time, remove the old key, increase CuC_uCu​ by one, set AuA_uAu​ to that submission's completion time, and insert the new key.

Multiple submissions by the same user to the same problem must increase the solved count only once. Store completed (user,problem)(\mathrm{user},\mathrm{problem})(user,problem) pairs in a hash set, and update the user ranking only when a pair is inserted for the first time. The duplicate check must be made at completion time, not at submission time: a later submission to the same problem may finish earlier on another server.

Every completed submission is still inserted independently into the per-problem ranking.

Processing queries

For a query at time ttt, first apply all completion events with completion time at most ttt.

  • For type 111, compute the new completion time using the server's last completion time and push the event into the min-heap.
  • For type 222, print the stored best records of the requested problem.
  • For type 333, print at most the first 555 entries of the user-ranking set.

Subtasks

For subtask 1, it is sufficient to rescan and sort all relevant completed submissions for every output query. Since the aggregate QQQ is at most 2 0002\,0002000, an O(Q2log⁡Q)O(Q^2\log Q)O(Q2logQ) solution fits.

For subtask 2, there is only one server and no type-333 query. Completion order equals submission order, so a queue of completion events and the best 555 records of each problem are enough.

For subtask 3, no user ranking is needed. Use a min-heap for completion events and maintain only the best 555 records per problem.

For subtask 4, there is one server, no type-222 query, and every (nickname,problem)(\mathrm{nickname},\mathrm{problem})(nickname,problem) pair is submitted at most once. A queue of completion events and the user-ranking set are sufficient.

For subtask 5, every (nickname,problem)(\mathrm{nickname},\mathrm{problem})(nickname,problem) pair is unique, so the completed-pair hash set is unnecessary. Maintain the event heap, per-problem top 555, and user-ranking set.

For the full constraints, add the completed (user,problem)(\mathrm{user},\mathrm{problem})(user,problem) hash set.

Complexity

Each submission is inserted into and removed from the completion-event heap once. User-ranking updates cost O(log⁡Q)O(\log Q)O(logQ), while updating a per-problem vector of size at most 666 costs O(1)O(1)O(1).

The complexity of one test case is O((N+Q)log⁡Q)O((N+Q)\log Q)O((N+Q)logQ) time and O(N+Q)O(N+Q)O(N+Q) memory. The aggregate bounds ∑N,∑Q≤200 000\sum N,\sum Q\le 200\,000 keep the total workload within the limits.

Solution written by GPT5.6

max(t,Fi​)+
y.
∑N,∑Q≤
200000