finish writing

README.md

@@ -11,6 +11,22 @@
 # 测试数据与调试经历
 主要经历了两次重大bug，第一次是在刚开始编写时，出现玄学错误，通过抛出异常等方法逐步排查最终发现是解析命令字符串时出错。第二次是在编写中期，排名维护反复出bug，用下发的测试数据分析，发现bug出在需要依次比较两个得分、罚时均相同的队伍的通过时间序列时，由于下发测试数据过大不便调试，因此我针对性地设计了一组测试数据`testcases/1.in`，并借助它修复了这个bug。在性能优化阶段，在重构刷新榜单函数使得它支持精确更新后，排名维护再次出bug，我同样借助`testcases/1.in`修复了bug。
 ___
+# 复杂度分析报告
+## 添加队伍
+O(1)，观察代码，AddTeam函数只初始化了后台数据（用随机访问数组存储），因此O(1)
+## 提交题目
+O(1)，观察代码，AddTeam函数只更新了后台数据并往暂存区简单地打tag，因此O(1)
+## 刷新榜单
+O(n log n)，观察代码，在刷新榜单函数中最多有N个队伍被更新，每次更新进行常数次查询、插入（O(log n)），因此O(n log n)
+## 滚榜
+O(n log n)，观察代码，滚榜函数一头一尾各调用一次刷新榜单操作，其中第一次同上述分析O(n log n)，第二次只遍历，均摊O(n)。滚榜自身，scroll_cursor保证了每个队伍的每道题最多被处理一次、最外层大循环最多进行N*26次，每次大循环进行常数次查询、插入（O(log n)）。综上，滚榜操作O(n log n)
+## 查询队伍排名
+O(1)，观察代码，相关函数直接查询跟随榜单刷新的一个随机访问数组，显然O(1)
+## 查询队伍提交情况
+O(1)，观察代码，相关函数直接查询后台数据，显然O(1)
+## 特殊说明
+在题目所给的数据范围内，unordered_map时间复杂度退化的可能性可以忽略不计，相关操作视作O(1)
+___
 # :trophy:ICPC Management System
 
 > ACM 班 2023 级程序设计课程第二次大作业