万年 2.4G 频段 wifi

@g67261831 谢谢，今天才知道原来 SF Mono 字体并不在系统字体目录下，怪不得 iterm2, idea, vscode 这些里面都选不到。

@Xs0ul 你说得对

DNSPod API 的封装一大把，连我自己都重新造过轮子。

然而我还不止跑了一次 4.4G ……

上面打错了一句，「你回过头去看上面 O(M*N*logN) vs O(M*N)的情况，相差的倍数会随着 MN 的变大越变越大」应该是「你回过头去看上面 O(M*N*logN) vs O(M*N)的情况，相差的倍数会随着 N 的变大越变越大」

@SoloCompany 大哥，你这算时间根本没把排序放进来啊。


@gam2046 我也是服气了，你后面贴的代码明明只排了一次序，和你之前贴出来的代码根本是两回事，我解释了半天根本是在浪费自己时间。

重新再给你讲一遍：
你在正文里贴的代码，假设外层循环 M 次，每次都随机生成大小是 N 的数组，先排序的时间复杂度是 O(M*N*logN)，不排序的时间复杂度是 O(M*N)。

你在评论里贴的代码，就直接把排序给移到外层循环外面去了！随机数组也只生成一次！！这还比个鬼啊！！！

这种情况下先排序的时间复杂度是 O(M*N+N*logN)，即 O((M+logN)*N)，在 M 远大于 logN 的情况下 logN 可以忽略不计，看成是 O(M*N)，而不排序的时间复杂度也是 O(M*N)，两者所花时间的是同一个**规模**，但先排序因为有常数 k 的优势(CPU 分支预测成功率高)，因而在 M 和 N 都比较大的时候会明显更快一点。我换个说法，先排序花的时间是 k1*O(M*N)，不排序花的时间是 k2*O(M*N)，虽然大头在 O(M*N)，但 k1 < k2 ，你会观察到前者更快。话说回来，你可以从时间上验证，两种做法所花的时间，在 N 一定的情况下，都是随 M 线性增长的，不管 M 或 N 多大，都是快一个固定的比例，不会有时快 1 倍，有时快 5 倍这种情况。你回过头去看上面 O(M*N*logN) vs O(M*N)的情况，相差的倍数会随着 MN 的变大越变越大。

至于你说的"之所以没有用同一个数组，是因为我试的时候发现用同一个数组，后测试的那个速度会明显加快"，当然会啊！因为你先测的先排序，又用同一个数组，后测的那个就直接是在排好序的数据上测了。

@gam2046 这是不可能的，不然要算法时间复杂度分析来做什么。

分支预测和语言无关，是 CPU 的事情。求和的算法复杂度是 O(N)，分支预测成功率不改变这个复杂度，只影响 O(N)外面的常量系数大小，即实际使用时间 k * O(N)的 k 值。

加上排序以后，时间复杂度一下就变成 O(NlogN)，只要 N 稍微大一点，分支预测省的那点时间根本不够看。作为参考，分支预测失败的 penalty 虽然大于 L1 cache 访问时间，但比 L2 cache 访问时间还要小点。

下面是我拿你的代码测的结果，只改了 long start = System.nanoTime() 的位置和生成数组大小

public static void main(String[] args) {
for (int loop = 0; loop < 1000; loop++) {
int[] data = new Random().ints(0, 256).limit(65536).toArray();
long start = System.nanoTime();
Arrays.sort(data); // <- 取消这行注释，对比运行结果

int sum = 0;
for (int num : data)
if (num > 128) sum += num;
long end = System.nanoTime();

System.err.printf("%d\t%d\t%d%n", loop, end - start, sum);
}
}

数组大小为 65536 时，
不排序，最后 10 次运行时间
990 161240 6209232
991 161415 6252012
992 161209 6283107
993 161179 6207880
994 166293 6220546
995 161209 6265626
996 1262967 6236605
997 161269 6199788
998 161101 6244670
999 161109 6239128

排序，最后 10 次运行时间
990 2426694 6264825
991 2553366 6255119
992 2510335 6234796
993 2381404 6253152
994 2500855 6278084
995 2502657 6264268
996 2466819 6235365
997 2455288 6237932
998 2404866 6247138
999 2416455 6199959

数组大小为 2048 时，
不排序，最后 10 次运行时间
990 5229 193642
991 5232 196327
992 5208 198862
993 5223 198061
994 5279 198222
995 5254 196125
996 5249 193539
997 5215 202792
998 5265 193889
999 5227 198240

排序，最后 10 次运行时间
990 89312 194321
991 88549 198128
992 98797 194627
993 88444 191445
994 90597 194749
995 90107 198396
996 89240 195159
997 88931 197912
998 90946 189114
999 89749 191097

事实上排序+求和无论如何也不会快过直接求和。

@gam2046 我去，原来你计时没有把排序的耗时算进来啊，那有什么好比的……

你的数据集太小，排序的 O(NlogN)时间复杂度相比分支预测省下的时间不显著。把你的随机数组大小改大，至少超过 L1 cache 大小的 2 倍(64K/4*2=32768)， NlogN 的威力会显示出来的。

Struts2 出来都十几年了，有什么好讨论的...难道国内有这么多 legacy 系统要维护？

拿 python 或随便什么语言写个脚本，用最粗暴的 n 平方复杂度扫所有表结构,然后生成
A -> B
B -> C
这样的引用关系

然后用 graphviz 生成图。

在 jenkins 全局配置里配置可用的 ruby 版本，在 project 配置里选择使用某个版本， jenkins 会自动在 slave 上安装和配置，各 project 也不会冲突。不要手动去 master/slave 上装特定版本的 ruby ，也不要在 project 里选择使用系统默认的 ruby 版本。

楼上的也别听风就是雨，老款 mbp 可以自己加内存换硬盘，扩展性上比现在的 rMBP 好得多。

主要的问题是电池，你得把换电池的成本也加进去。

@morethansean 我都试过...

这么说吧， Google 都是用 google docs 在远程面试里让人写代码。

@richard1122 学习了

@redsonic hsts 是网站自己声明，然后浏览器保存设置，不是浏览器自带列表