Source code is a non-linear representation, which contains a variety of complex structural information. When the DFG and CFG structural representations are used to create a model's understanding of code, it makes a significant improvement in the model's ability to understand the semantics of the code. Although GraphCodeBERT (Guo et al., 2020) incorporates Data Flow Graphs (DFG), it uses them implicitly during pre-training for variable alignment. In contrast, GFTrans employs an explicit “anchor-based” strategy. We inject discrete 〈DEF〉 and 〈USE〉 tags directly into the token sequence. This preserves precise define-use chains and forces the attention mechanism to actively track data dependencies during runtime prediction, ensuring a stronger grasp of code logic. One of our key challenges is the effective conversion of code graph structures into a linear representation that can be processed by Transformer-type architectures, without losing the underlying logical structure of the code or its data dependency. To address this, we present a linearization of the graph structure using dedicated anchor markers. this strategy is implemented in four steps.

Step 1: By using the static code analysis tool Joern, we are able to create a Code Property Graph (CPG) for the C function target being analyzed, from which we can identify three types of code collections. (1) Statement Node Set V: it contains all statement-level nodes and the associated source code that is represented. (2) Control Flow Edge Set E_CFG : a directed edge set that shows the relationships of execution jumps between statements within a CFG format. (3) Data Dependency Edge Set E_DFG: a directed edge set that defines the “Def-Use” relationship chains, allowing us to ascertain all statement nodes defining data and usage statement nodes within a specific application process.

Step 2: To ensure ease of recognition when navigating through multiple code basic blocks of a series, a global indexing system be implemented to represent data segments within the code throughout the E_DFG set. We iterate through all data definition locations, and when we identify a data definition node in V (v_def∈V), we assign it a unique numeric identifier ID(v_def) = N (where N∈{1, 2, …, M} and M denotes total data definitions found in the function); this unique ID is used as a reference when accessing the data in the code tokens.

Step 3: Figure 2 illustrates that the program launches in sequential order as defined by the execution of each of the statements. The networkX library provides an API to generate an control flow graph structure using python. Using a Depth-First Search (DFS) Technique, we can sample a CFG via traversal from the starting point to the end point, thus creating a Path where every statement Node encountered during the traversal path for a defined statement node is recorded. As a CFG may contain cycles, we track the number of times a statement node has been visited, limiting it to a maximum of two visits. This technique, therefore, allows traversing the cycle and reaching an endpoint without creating a continuous Loop. As we construct paths from the CFG , any code fragment results in a Collection of Execution Paths. Therefore, the Set of Paths Created from Within the CFG Graphs are Defined as P={P1,P2,…,PK} where K = number of paths established. Each path P consists of a List of Statement Nodes; And P = [s₁, s₂, …, s_L] and s_i = the i-th Statement Node in the Path. The arrangement of code statement sequences according to the control flow path reflects how the program is executed.

Step 4: Figure 3 illustrates the process of inserting data anchors into the code execution path. This embedding technique represents a key innovation of our work. Specifically, we develop a method to extract discrete DFG data and seamlessly incorporate it into continuous code execution sequences. For each statement node s_i in the sampled path P, information from the E_DFG is retrieved and structurally augmented to the execution path sequence of s_i by the addition of specially structured markers, as follows. For example, if the statement node s_i represents a data definition point and there exists a parent data anchor ID assigned to s_i in step 2 identifier N_ID, we embed a unique definition marker tag <DEF_{N_ID}> into the textual content of statement Node s_i. If s_i uses one or more data types specified from data definition point anchors in the E_DFG, we locate all data definition point anchor IDs associated with s_i and will append the appropriate Number of use tags <USE_{N₁}>, <USE_{N₂}> into the textual representation of the statement node s_i.

After enhancement, the path set retains the semantics of its original execution flow. However, explicitly defined data flow markers within the path can be combined with the separator label [SEP] for utilization in the final execution path sequence. In order for the model to recognize the data structure embedded in the execution path, All unique anchor Tags (e.g., <DEF_1>, <USE_5>) must also be available to the word vocabulary of the pre-trained CodeBERT Model. After tokenization, truncation or padding the sequence to a pre-determined Length, the sequence must then be transformed into a fixed-length token ID sequence. The result is a guidance input to the model, which facilitates the full integration of control flows and data flows.

The Transformer-based deep learning approach has demonstrated the ability to comprehend the semantics of code (Vaswani et al., 2017). Utilizing various code features allows an analyst to evaluate the complexity of a code base and allows the deep learning model to attain the most relevant inductive biases, based upon a larger scope of coding features. This research uses the feature set developed by Sikka et al. (2020), who produced a set of features based upon statistical analysis techniques to assist in the development of models to predict the runtime complexity of code. We implemented a total of 24 features using SourceMonitor tools based on source code generation, along with custom-written scripts to develop a 24-dimensional feature vector. These features are categorized across four distinct structural complexity classes.

Sikka et al. (2020). demonstrated that the depth of nested loops and the number of branches in the code structure are important indicators of the computational efficiency of a code base. Therefore, we has produced a total of 24 features based upon source code using a tool named SourceMonitor, along with custom written scripts to develop a 24-dimensional feature vector; these features are based upon four different categories of structural complexity.

The structural complexity features category includes items such as nested loop depth, number of Loops, number of Ifs, number of Switches, and maximum Block depth. The count of methods category includes IO keyword counts, counts of total statements, counts of total variables, and counts of total code lines, as well as the high overhead costs associated with executing IO calls. The algorithms patterns category includes the number of sorts associated with sorting, whether recursion is present, whether a priority queue is present, whether a hash map is present, and a variety of other elements.

Lastly, the control flow fragmentation characteristics category includes the total number of jumps, breaks, continues, and returns to illustrate the extent to which the execution of a program has deviated from its intended path. The original 24-dimensional features developed in this research have the potential to contain noise or redundancy. Using Spearman rank correlation, we investigat the correlation between code features and run times of the code in the training set. From the training set labels, we calculate the Spearman Correlation Coefficient ρ to determine monotonic relationships between feature values and runtime of the code.

To empirically validate the necessity of these handcrafted features, we calculated the Spearman rank correlation coefficients for all 24 features against the runtime labels and plotted the top 8 most influential features in a bar chart (Figure 4). As expected, structural features rank the highest, with “Nested Loop Depth” (0.72) and “Number of Statements” (0.68) demonstrating the strongest positive correlation. This confirms that algorithmic complexity, driven by loops and code size, is the primary determinant of execution time. “Number of I/O Operations” also shows a strong correlation (0.55) due to the inherent latency of I/O calls. Interestingly, while “Percent Comments” has a lower correlation of 0.36 (below the 0.4 threshold), we retained it intentionally as a semantic proxy to assist the model distinguish between complex human-written logic and simple auto-generated code.

We specifically included “Percent Lines with Comments” as a key feature. Comments are stripped away by the compiler. They do not physically slow down the execution.We included this feature as a semantic indicator. The decison is grounded in the coding conventions of open-source communities. Firstly, developers tend to write detailed comments for complex algorithms. These algorithms usually fall into the “Long” execution category. Therefore, this feature acts as a “helper.” It helps the model estimate the complexity of the logic. we delete the Line feature and retained only the statement feature, which is better representative of how many statements are in each piece of code. Thus, the feature set has been reduced from 24 dimensions to 16 features of superior quality, as shown in Table 1.

By employing the CFG, we generated a collection of Paths P={P1,P2,…,PK}, where each path contains a traverse of all the properties of code and the Anchor Points representing their flow of data, using the edges associated with every path. The procedures employed to produce each dimensionality reduction vector are consistent with each of the paths that are sampled (i.e., K = 10). Initially, the CodeBERT pre-trained tokenizing method is utilized to convert each P_i (the i-th sampled path) into an array of sub-word token IDs. Simultaneously, we assign a unique anchor ID (i.e., <DEF_N>, <USE_N>) to each of the IDs associated with each path. The final representation is denoted as T_i.

Subsequently, T_i is processed by the backbone network, where tokens in T_i capture long-distance relations through self-attention within the Embedding layer and the 12-layer Transformer encoder. The resultant output vector aligns with the input representation at position [CLS]. Thus, the semantic representation of an individual path h_i is created as follows:

where d_model is equal to 768. After the process of dimensionality reduction is completed for each code sample, the h_i vectors form a collection of d_model dimensional vectors H = {h₁, h₂, …, h_K}, where each vector represents a different execution flow and its associated data dependencies.

Execution paths in programs affect performance differently (for example, execution paths within the main loop of an algorithm significantly impact performance compared to paths in exception handling or initialization). Therefore, basic average pooling fails to capture these crucial structural differences. Inspired by Hu et al. (2025) and their use of soft-attention in graph-level readout operations for GNNs, we introduce a path-level attention mechanism to dynamically aggregate multiple path features. This mechanism allows the model to automatically learn the importance weight of each path.

We introduce a trainable context query vector u∈ℝdmodel. For each representation vector h_i within the path set H, we first calculate its importance score s_i through a nonlinear transformation, and then apply a softmax function to normalize the score, obtaining the attention weight α_i for the i-th path:

where W_att and b_att are trainable parameters, and K is the total number of paths. The weight α_i quantifies the contribution of the i-th path to determining the current code's runtime category. The final code semantic vector v_sem is produced via the weighted sum of all path vectors:

This process compresses the K×768 path matrix into a single 1 × 768 global vector, effectively highlighting the semantic features of key execution paths while suppressing noise from irrelevant paths.

In the feature engineering phase, we screen out a 16-dimensional high-quality handcrafted feature vector fraw∈ℝ16 (including nested loop depth, IO keyword frequency, etc.). Since the dimension of handcrafted features is far lower than that of semantic vectors and the numerical distribution varies significantly, direct concatenation would cause the explicit features to be overwhelmed by high-dimensional semantic features. Therefore, we design a two-layer Multi-Layer Perceptron (MLP) as a feature projection module. First, we perform Z-Score normalization on f_raw to obtain f_norm, and then project it to the same dimension space as the semantic vector:

where W1∈ℝ16×64 transforms the features to an intermediate layer, and W2∈ℝ64×768 further maps them to the target semantic space. The projected vfeat∈ℝ768 can then interact with v_sem in the same manifold space.

To adaptively adjust the contribution ratio of deep semantic features and code features in the final prediction, we adopted a dynamic gating unit. The gating vector z∈(0, 1)⁷⁶⁸ is generated by jointly analyzing both feature streams:

The final fused vector v_final is computed via element-wise multiplication (⊙). To ensure dimensional consistency, the handcrafted feature vector is projected to match the semantic vector's dimension, so vsem,vfeat∈ℝ768. The gating vector z is also generated in ℝ⁷⁶⁸. The fusion equation is defined as:

where ⊙ represents element-wise multiplication. This mechanism allows the model to preserve deep semantics in certain dimensions (such as capturing data flow dependencies) while directly utilizing explicit features in others (such as exponential complexity signals brought by loop depth). Finally, the fused feature vector v_final is input to the classification head, which consists of a fully connected layer and a Softmax activation function, outputting the probability distribution of four runtime categories:

The model training uses the standard Cross-Entropy Loss function:

where N is the batch size, y_{i, c} is the true label of sample i belonging to runtime category c, and P_{i, c} is the predicted probability.

To provide a holistic view of the proposed framework, we formalize the complete training procedure in Algorithm 1.

As shown in Table 3, the GFTrans model outperformed the leading baseline model (Code2Vec) by 2.5% points in accuracy and 2.3 percentage points in the F1 score. This indicates that the “CFG/DFG graph structure fusion” (herein referred to as “our approach”) produces additional improvement in prediction accuracy compared to other approaches, showing the value of following execution paths through the use of CFG and DFG data structures.

The structural aspect of representation appears to have an advantage over unstructured forms of representation. The results indicate that models using code structure features (herein Code2Vec and GFTrans) produced more accurate prediction results than those based on flat features alone (Random Forest and LSTM). Code2Vec was able to outperform Random Forest by 1.3% points (Code2Vec = 76.1%, Random Forest = 74.8%), suggesting that hierarchical representations of code enable a better understanding of the logic contained within source code. The GFTrans model outperforms the Code2Vec model, it shows that compared to the static syntax tree features used by Code2Vec, dynamic control flow graph (CFG) and data flow graph (DFG) information are more efficient and accurate in predicting “runtime.”

In the case of sequential models (LSTM), the accuracy falls short compared to that of GFTrans (73.6%). The limitations of sequentially representing code are evident in the low LSTM accuracy. The nature of function calls and looping jumps creates long ranges of dependency that cannot be well learned by a simplistic sequential learning algorithm.

A comprehensive assessment of the efficacy of each model type across the runtime category is provided in Table 4. The experimental results indicate that all models exhibit relatively low prediction accuracy when predicting the two categories of “short” and “medium.” The accuracy of the baseline model hovers around 70%. The runtime differences between these two categories of code are not significant, with the main distinctions lying in the number of memory accesses, IO operations, and other time-consuming code statements. GFTrans achieves a runtime accuracy of 74% for these two categories, thanks to the introduction of manual code features that quantify the impact of time-consuming statements, thereby distinguishing minor performance losses caused by frequent memory operations.

GFTrans achieves an accuracy of 80.2% and an F1 score of 79.5% for the “long-duration” category. This result highlights the effectiveness of our graph structure fusion strategy. In real-world scenarios, long-running programs often involve complex control flows and data dependencies. Baseline models tend to under-predict execution time because they treat code as simple sequences. In contrast, GFTrans fuses Control Flow Graphs (CFG) and Data Flow Graphs (DFG). This fusion enables the model to track long-range dependencies within deep loops and recursive calls. Consequently, GFTrans accurately captures the structural complexity that leads to long execution times.

To demonstrate the stability and convergence of our training process, we visualized the learning curve in Figure 5. Figure 1 depicts the Training Loss and the Validation Accuracy over 25 epochs. As shown in the figure, we observe the training loss (red line) decreases rapidly during the first 10 epochs, suggesting the GFTrans efficiency learns features from the code graph structure. The validation accuracy (blue line) rises quickly and stabilizes after Epoch 15. The accuracy fluctuates slightly around 78.6% without any significant drops. The gap between the training loss and validation accuracy remains reasonable, indicating the model generalizes well to unseen data. Furthermore, these curves justify our decision to use “Early Stopping.” Stopping the training at 25 epochs is sufficient to get the best performance without wasting computational resources.

Furthermore, to better understand the nature of the misclassifications, we analyzed the results using a Confusion Matrix, as shown in Figure 6. The matrix reveals a clear and meaningful pattern. Firstly, the values on the diagonal are very high. This confirms the strong performance of GFTrans. Second, as you suspected, most errors happen between neighboring categories. For instance, the model sometimes confuses “Short” with “Medium.” But the model rarely makes severe mistakes. It does not confuse “Ultra-short” with “Long.” The errors mostly come from borderline cases. For example, a function runs in 98ms. The threshold is 100ms. The model might predict “Medium” (Category 2) instead of “Short” (Category 1). This is reasonable. Our calculation shows that about 88% of all misclassifications involve adjacent classes.

To verify the intended design of GFTrans, each component of GFTrans was removed one at a time, and the impact on accuracy, F1 score, and overall accuracy was measured. The results of this study are displayed in Table 5.

As shown in Table 5, removing graph-structured paths causes the accuracy to drop to 75.1%. This performance is lower than that of Code2Vec. This result validates our “data flow enhanced CFG linearization” component. It distinguishes GFTrans from prior work. Lexical co-occurrences alone are insufficient to determine program operations. They fail to capture control flow transitions that lack direct lexical relationships. Therefore, the directionality and structure of a CFG are essential. However, the CFG alone is not adequate. Comparing the CFG-only model with GFTrans reveals an accuracy gap of 1.4%. This increase comes from the addition of data flow paths. This supports the claim that control flow must be used with data flow. Together, they accurately determine the execution operation. This mechanism captures the definition and usage sequences of variables. Consequently, the model accumulates precise variable states to predict execution duration. We also evaluate the handcrafted features. Removing them from the network decreases accuracy by 1.5%. This indicates that these features introduce significant informative guidance. When code segments contain semantic ambiguity, these features act as “calibrators.” They provide rigid metrics to correct the model's predictions.

The plain concatenation of the feature vectors yielded a performance that was 1.0% lower than when the Gated Fusion method was employed. This suggests that code execution can be impacted by both the semantic and structural properties of the code. The Gated Fusion method allows for the model to selectively focus on the most informative features and eliminate those that are less informative. This enables the multimodal data to work together in a synergistic manner, allowing for adaptive synergy among the multimodal data.

Compiler optimization levels (GCC's -O0, -O2, -O3 and Os) have an impact on the relationship between program's characteristics and its runtime. The different levels of optimization produce machine code that creates a different set of runtime labels. To investigate the GFTrans model architectures' generality and flexibility under varying conditions of compilation, the experiments below were developed:

Table 6 summarizes the results of the above experiments. GFTrans achieves an accuracy of between 77 and 79% for either -O0 (preserving all redundant instructions) or -O3 (through intensive rearrangement of instructions). This indicates that the GFTrans graph-structured path and feature representation method proposed in this work is capable of generalizing robustly, allowing it to adapt to all compiler optimization conditions rather than exclusively overfitting to the unique characteristics of -O2. Finally, the accuracy of GFTrans under the -O3 condition (78.12%) is very close to that achieved under -O2 (78.64%). The fact that optimizations at the compiler level may have changed the quantity of executed instruction counts, but did not alter the time complexity class. It confirms that GFTrans captures the logical structure of the execution at a higher level using CFG/DFG, and is, therefore, the most robust against changes made by compiler optimization. In addition to speed optimizations (-O2, -O3), we also investigated the -Os flag, which optimizes for code size. Our supplementary test showed that GFTrans maintains a robust accuracy of 76.92% under -Os. The slight performance drop (compared to 78.64% under -O2) is expected, as -Os prioritizes smaller binary size over execution speed (e.g., by disabling loop unrolling), which can subtly alter the control flow structure used by our model.