在其他条件相同的情况，fuzz性能的提升往往对于fuzz有事半功倍的效果，下面主要来源于afl文档的翻译
1、test cases保持小一点
大的测试用例需要更多时间与内存去解析，在模糊测试的其他步骤效率也会降低
假如你收集的样本很多很大，可以使用afl-cmin去减少数量，再用afl-tmin去减少每个样本的大小
最好不要超过1M，比如afl作者提供的testcases都是很小的，图片基本是10K以下的
https://lcamtuf.coredump.cx/afl/demo/afl_testcases.tgz
2、使用更简单的目标
就是目标二进制尽量简单，毕竟执行的代码也少了
3、使用llvm插桩
默认的llvm插桩可以获得两倍的性能提升了
llvm模式下还有一个persistent模式，类似于in-process fuzzing mode，libfuzzer就是这种，性能就可以5-10倍了，不过也得看情况，有时可能只是2倍。而deferred fork server模式对于启动开销大的程序性能提升明显，这两种模式都需要编辑源码，但基本就是几行代码的事情。
4、分析优化目标二进制文件
比如有没有提高性能的参数，并不影响fuzz结果，比如测试图片处理程序，输出低质量的性能会好点；还有可以禁用输出以提升性能
还有ASAN编译的二进制对于性能的影响还是挺大的，可以考虑使用普通插桩程序fuzz，使用asan编译的二进制去过一下样本。
还有些程序使用sleep(), usleep(), or nanosleep()，——我觉得作者的意思是看看能不能删除或者减少sleep的时长？
还有其他的比如fsync()，可以使用libeatmydata来禁用，它其实是个LD_PRELOAD library
5、只插桩你需要的部分
只对我们想要测试的库插桩，全部库插桩便会降低fuzz的性能
6、并行执行fuzzer
可以启用一个-M，多个-S的方式启用多个afl-fuzz实例，还可以考虑多主机fuzz
7、控制内存使用和超时
使用-m控制内存限制，-t控制超时时间，太大可能对性能有影响，但是有时候不是用-m none，程序又fuzz不了。
对于-t，作者建议在空闲并且性能不错的机器，将时间-t下降为5可能是可能的，但是这个具体还是要看情况啦，默认也没什么大问题，可以对比下性能，自行选择
8、检查操作系统的状态与设置
下面几个因素会影响模糊测试的速度
- 高系统负载。所以使用空闲的机器，不要运行任何不必要，还要占用cpu的程序（浏览器，播放器等）
- 网络文件系统（毕竟网络的，我觉得还是用本地吧），比如fuzzer的输入输出目录，fuzz目标需要的config文件，看着作者也不推荐在home目录，因为很多程序在那里搜索点开头的文件（点开头其实就是隐藏文件或目录）
- CPU按需分配，有时linux系统可能低估了afl或者模糊测试器的短暂的性能需求，linux可以通过下面命令配置
1 | cd /sys/devices/system/cpu |
- 禁用Transparent huge pages，假如这个启用，某些内存分配方案（例如 jemalloc） ，会对模糊测试的性能影响很大，可以通过如下命令禁用
1 | echo never > /sys/kernel/mm/transparent_hugepage/enabled |
- 次优的调度策略，这个可能因目标而异，linux作者推荐如下配置
1 | echo 1 >/proc/sys/kernel/sched_child_runs_first |
9、如果上面都无效，使用-d
这个模式可以使afl-fuzz跳过所有确定性的模糊测试过程
参考
https://github.com/google/AFL/blob/master/docs/perf_tips.txt
