然而只是个简单的整理而已 也就自己看看
大概是个备忘录的样子？
UPD on 2023/1/1 :
声明一下，这篇文章的内容可能有错误，请不要轻易相信，除非你已经写代码验证过了
为啥不修锅？因为我懒，，
就这样
- 处理多组数据时写
for ( ; T; --T)最高效 - 短路运算、三目运算比
if快 ++i比i++快，--i比i--快- 逗号运算符比分号快
- 取模
%是最慢的运算 long long的常数是int的两倍- 访问数组元素比访问单个变量慢很多
int是最快的，甚至比bool还要快memset/memcpy比for循环赋值快很多- 用
define实现min/max容易造成重复计算，增大常数 - 访问最频繁的几个变量应该丢进寄存器
- 在浮点数运算中应尽量减少
/的运算次数 1ll*x*y%P比(ll)x*y%P快- 若答案对一个
int范围内的数取模，则绝大部分变量都不必开long long - 尽量避免使用
STL，sort除外 - 一般
unordered_map比map快 - 合理使用位运算优化
*,/和% - 不要使用
cin/cout - 输出字符时
putchar是很快的，输出字符串时puts是很快的 - 若函数体内包含循环但循环次数很少，可以使用
inline - 包含递归、循环（第20条情况除外）或者函数体较长的函数不要加
inline strlen的复杂度是线性的，最好把结果存到变量里使用clock()测用时很准，但注意过多调用它也会影响程序效率- 慎用预处理，即使可以避免重复计算（理由见第7条）
- 尽量不使用
long double，它的常数很大 - 浮点数除法很慢，应使用交叉相乘等技巧尽量减少除法运算次数
- 尽量紧凑关系密切的代码，即使这样会导致码长增加
- 写 FFT\rm FFTFFT 时应当预处理三角函数值（这属于第24条中的“慎用预处理”）
- 与第28条相反，写 NTT\rm NTTNTT 时不应预处理乘方值
- 不要相信网上流传的40行优化，其中大部分都很少起到作用
- Ofast\rm OfastOfast 优化是较为有效的一种优化（这不属于第30条中的“大部分”）
- 应尽量让小数组的大小能够卡进cache
- 在理论复杂度相同时，迭代实现往往比递归实现更快
- 在循环展开可能破坏代码的结构和可读性时，慎用循环展开
- 不应为简化代码而舍弃效率（第34条情况除外）
本文链接：https://my.lmcjl.com/post/7561.html
展开阅读全文
4 评论