带杀软编译到底会拖累你多少性能？20%左右 —— 再做杀软编译测试

显示全部楼层 · 发表于 2020-7-31 16:23:15

本帖最后由 popu111 于 2020-7-31 17:41 编辑

废话不多说，前置可以看 https://bbs.kafan.cn/thread-2166317-1-1.html ，这里提几个问题：

1. 因为编译用时太短，所以数值可能的波动范围较大，影响结果

2. 使用虚拟机测试，难以保证资源独占，cpu分配波动可能较大，io缓存问题无法量化

3. 根据 @B100D1E55 大佬的猜测，认为大型编译项目会可以有助于杀软表现出真正的，因为扫描和行为造成的延迟

4. 虚拟机内网络环境可能不适合某些杀软发挥造成较长的云查询io耗时

然后是对这些问题的解决：

1. 选择firefox作为这次测试的编译项目，选择ff而不选择chrome的主要原因是chrome的那个编译依赖管理工具太难用了，如有可能尽量不想再用了

2. 改用独立物理机进行编译，ThinkPad X1C 6，8350u + 16G + 250g西数黑盘，win10 老坛酸菜 2019，关闭更新、搜索索引，打开性能模式，散热环境固定，室内温度常年26度

简陋但恒定的测试环境

3. 虽然个人认为rust的编译行为已经足够模拟情况了（cargo会为依赖的每一个包现释放一个编译程序，这也是上次造成avast炸掉的原因），但是这次换的项目应该足够大了

4. 在测试平台上面使用r**cloud的梯子，通过大力氪金提高网络质量

结果：裸机编译耗时 68:38.96
这次的结果让我敢于做量化的比较了，直接来比例吧

结论：BD牛逼

又及测试方法：为防止扫描缓存干扰，测试流程均为：安装 - （打断可能有的扫描） - 更新 - 重启 - 执行编译测试 - 回滚系统 - 关机冷却（时间不定，主要看我什么时候想起来进行下一个测试）

补充：
- 关于骚护士Homo：测了，关了exploit保护，加白都不好使，不让mingw分配堆，找不到标准库……一堆问题，心累了，不会有人想顶着这傻逼玩意搞生产力吧？

显示全部楼层 · 发表于 2020-7-31 16:24:56

基本和预料的差不多，哈哈哈

显示全部楼层 · 发表于 2020-7-31 16:39:37

测试辛苦了，跟我使用的情况确实是非常接近，绝对的极品测评

显示全部楼层 · 发表于 2020-7-31 16:43:31

波比鸡大佬太强了(此条一次py交易，发送时括号内删除)

显示全部楼层 · 发表于 2020-7-31 16:46:20

我看到了特若200？

显示全部楼层 · 发表于 2020-7-31 16:47:55

pal家族发表于 2020-7-31 16:46
我看到了特若200？

拿来存系统快照，在PE里用ati再恢复回去，特弱200干不了别的，干这个还行

显示全部楼层 · 发表于 2020-7-31 16:49:41

popu111 发表于 2020-7-31 16:47
拿来存系统快照，在PE里用ati再恢复回去，特弱200干不了别的，干这个还行

你这个是越大越卡？还是越大越流畅啊
直接告诉我吧工作好忙不想思考

显示全部楼层 · 发表于 2020-7-31 16:50:31

pal家族发表于 2020-7-31 16:49
你这个是越大越卡？还是越大越流畅啊
直接告诉我吧工作好忙不想思考

越大越卡，橙条的意思是慢了多少

显示全部楼层 · 发表于 2020-7-31 17:04:28

火绒竟然比ESET影响小，BD真安全

显示全部楼层 · 发表于 2020-7-31 18:12:21

本帖最后由 85683213 于 2020-7-31 18:16 编辑

BD 完全就是因为程序运行时atc的初始注入太卡，可能是并发不行
在网路不好的地方atc甚至会查询信誉到timeout才会放行

因为这种编译就是compiler一直反覆运行

三年前的一点经验

我觉得楼主可以考虑多做一些测试，看是因为File System还是Execution造成的
甚至是有缓存和没缓存的比对其实也很有意义

[技术原创] 带杀软编译到底会拖累你多少性能？20%左右 —— 再做杀软编译测试

本帖子中包含更多资源

评分

评分

评分

评分

评分