## 5 Evaluation  
We run all our evaluations on a 64-bit server running Ubuntu 18.04.5 LTS with two Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40 GHz CPUs (16 cores in total) and 125 G memory. Our evaluation aims to answer the following questions.  
1. **Performance overhead**: How much performance overhead does EtWExplorer introduce compared to traditional path exploration technology?
2. **States space explosion mitigation**: How much more effective does EtWExplorer mitigate state space explosion compared to traditional path exploration techniques?
3. **Path exploration capability improvement**: How much improvement is EtWExplorer's path exploration capability compared to traditional path exploration technology?  
Since EtWExplorer needs to analyze and record the abstract syntax tree during execution. In this way, it reduces the priority of a part of the states and even prunes a part of meaningless states when the state space explodes. EtWExplorer is essentially a time-efficiency trade-off technology. Therefore, our experiments tested EtWExplorer in two areas: performance overhead and path exploration capability. For the control group, we select some common path exploration techniques.  
1. Lengthlimiter technique: Length-limited breadth-first exploration technique. We use this technique as a representative of path exploration techniques based on tree search algorithms.
2. Veritesting [9] technique: The local control flow graph-based path exploration technique. We use this technique as a representative of path exploration techniques for generating local control flow graphs.
3. Angr's Explorer [8] technique: The global control flow graph-based path exploration technique. We use this technique as a representative of path exploration techniques for generating global control flow graphs.
4. Coverage-based technique: Coverage-based path exploration technique. We use this technique as a representative of path exploration techniques based on coverage.  
Here, we did not use the manual merge point technique as a control group. This is due to the fact that the manual merge point technique requires manual assistance. We consider it fairer to experiment without manual assistance for all tested techniques.  
We used some real-world programs as the test set for this paper. For different experimental purposes, we divide the test programs into two categories. One category involves programs that do not cause a state space explosion. We use this category of programs to test the performance overhead introduced by EtWExplorer. The other category involves programs that cause a state space explosion. We use this category of programs to test the priority scheduling and pruning strategy to improve path exploration capability. We choose \"ffmpeg\", \"ffprobe\" in the ffmpeg and \"nm\", \"objcopy\", \"objdump\", \"readelf\", \"size\", \"strings\" in the binutils to represent the first category of the programs; choose \"guetzli\", \"jhead\" and \"pddfdetach\", \"pdfimages\", \"pdfinfo\", \"pdftotext\" in the xpdf to represent the second category of the programs. By testing different categories of programs, we can better understand EtWExplorer's effect on different categories of programs.  
Since there are exploration approaches whose performances can be severely affected by state space explosion, we put a limit on the execution time and the amount of memory space used for the experiments. In this paper, the execution time of the path exploration capability test was limited to 6 h and the maximum memory space used was 20 GB. If the limit is over, the path exploration will be automatically terminated.