## 4 Performance Evaluation
### Performance Evaluation Results  
The performance evaluation compared the proposed scheme with a modified version of Subway, a static graph processing scheme adapted for dynamic graph processing, and EGraph, a dynamic graph processing scheme. This comparison assessed the performance differences between the proposed scheme and existing approaches, demonstrating the efficiency of the proposed scheme in dynamic graph processing. The experiments were conducted using the sk-2005 and twitter7 datasets, with the data modification rate set to 0.01%. The evaluation employed the Connected Components (CC), SSSP, and BFS algorithms. The x-axis of Figure 8 represents the algorithms being compared. In Figure 8, the x-axis represents the algorithms under comparison, while the y-axis indicates the performance improvement ratios of EGraph and the proposed scheme relative to Subway (baseline set at 1). In Figure 7(a), the proposed scheme achieved 348%, 243%, and 303% faster processing speeds compared to Subway, and 104%, 109%, and 108% improvements over EGraph. In Figure 7(b), the proposed scheme demonstrated 229%, 287%, and 271% faster speeds than Subway, and 100%, 120%, and 108% faster than EGraph. Figure 8: Performance comparison with various existing schemes. The performance differences arise from the distinct processing approaches of each scheme. Subway processes only one snapshot at a time, resulting in relatively slower execution. EGraph supports dynamic graph processing but does not consider tentative active vertices during scheduling and lacks an operation reduction method, leading to unnecessary computations and suboptimal performance. The proposed scheme overcomes these limitations through priority-based scheduling, which accounts for tentative active vertices to efficiently determine the GPU processing order, and operation reduction techniques, which eliminate duplicate computations across snapshots. This enables more efficient partition processing in response to dynamic graph changes. Therefore, the proposed scheme achieved up to 348% faster speeds than Subway and 120% faster speeds than EGraph, maximizing resource utilization and computational efficiency in dynamic graph processing. Figure 9 presents a breakdown of graph processing time for different algorithms (CC, BFS, SSSP) using Subway, EGraph, and the proposed method, evaluated on the twitter7 dataset. The graph illustrates the proportion of data accessing Time (blue) and vertex processing time (orange) for each approach. As shown in Figure 9, the proposed method significantly reduces the data accessing time compared to both EGraph and Subway. Specifically, in Subway, the data accessing time accounts for more than 50% of the total execution time, indicating frequent CPU-GPU memory transfers. In contrast, EGraph reduces this overhead by sharing common graph data across multiple tasks, minimizing redundant memory transfers. However, the proposed method further decreases data accessing time to less than 35% across all algorithms, while increasing vertex processing time to over 65%, demonstrating improved GPU resource utilization. This is primarily attributed to the operation reduction and priority-driven scheduling techniques used in the proposed method. Unlike Subway and EGraph, which often reload overlapping graph partitions into GPU memory, the proposed method caches shared data more effectively and prioritizes computation over unnecessary memory transfers. As shown in Table 4, the proposed method significantly reduces memory transfer volume across different algorithms. Specifically, compared to Subway, the proposed method achieves a 72% reduction for CC, 75% for BFS, and 70% for SSSP. Additionally, compared to EGraph, the proposed method further reduces memory transfer volume by 20% for  
Figure 9: Graph processing time breakdown. CC, 14% for BFS, and 21% for SSSP, demonstrating a substantial reduction in unnecessary CPU-GPU data transfers.