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

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

本帖最后由 popu111 于 2024-9-25 19:28 编辑

废话不多说，前置可以看 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. ************ 保障网络质量不影响测试

结果：裸机编译耗时 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造成的
甚至是有缓存和没缓存的比对其实也很有意义

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

85683213 发表于 2020-7-31 18:12
BD 完全就是因为程序运行时atc的初始注入太卡，可能是并发不行
在网路不好的地方atc甚至会查询信誉到timeo ...

并发不行导致编译变慢，这本身就是我想要体现出的问题

有无缓存的对比可以在上一个测试中看到，当然是杀软缓存+系统用内存缓存+vm缓存加持下的加强版

再做一遍带缓存的测试在我看来没有必要，主要是太浪费时间来

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

本帖最后由 a27573 于 2020-8-23 20:54 编辑

火绒和ESET两主打动启的竟然第一第二。。。也许生成大量exe时才会明显拖慢？

反正一年前我可以明显感觉到火绒4.0卡编译，具体表现就是在测评程序的时候，第一个测试点总是会报错（超时、阻塞之类的）

P.S. 这里指的是OI中的测评，用CCR-Plus测评器，我也不知道测评器作者是怎么考虑的，每测一个数据点都会都会重新编译一次程序，然后一般每道题都是20个数据点起步

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

a27573 发表于 2020-7-31 19:02
火绒和ESET两主动动启的竟然第一第二。。。也许生成大量exe时才会明显拖慢？

反正一年前我可以明显感觉 ...

这个情况恰好和我上一次测试相符，个人推测火绒并不是对于大量卡，而是对于短期内编译器的首次运行会卡下来扫描，对于这样一个较大的项目，后续的执行时间因为较快，所以拖平了初始运行的缓慢，一开始慢反而成了特异数据

可惜忘记了保留日志，不然可以分析一下

显示全部楼层 · 发表于 2020-7-31 22:00:11

大佬牛啊，不知道毒霸在这环境下咋样。。

显示全部楼层 · 发表于 2020-7-31 22:03:09

膜拜大佬

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

我看见你东芝最后一款OCZ配色固态了....

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

已经卸载了Sophos，我做设计，Sophos真的拖慢系统

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

辛苦测试了。跟我部分实际使用感受一致。

显示全部楼层 · 发表于 2020-8-1 01:08:49

761773275 发表于 2020-7-31 22:37
已经卸载了Sophos，我做设计，Sophos真的拖慢系统

老哥你不是刚买了Sophos不久……

显示全部楼层 · 发表于 2020-8-1 01:15:13

本帖最后由 761773275 于 2020-8-1 01:18 编辑

popu111 发表于 2020-8-1 01:08
老哥你不是刚买了Sophos不久……

低价收的，收破烂

sophos能不能说详细点，sophos其实还不错的，就是技术不成熟，还有差不多有20个后台程序

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

本帖子中包含更多资源

评分

评分

评分

评分

评分

评分