Program performance analysis method and device and electronic equipment

Abstract

The invention provides a program performance analysis method and apparatus, and an electronic device. The method comprises the steps of obtaining an intermediate representation of a to-be-analyzed program based on a compiler plug-in; determining multiple pieces of performance data of the to-be-analyzed program based on the multi-dimensional performance characteristics of the intermediate representation; identifying abnormal performance data in the multiple pieces of performance data, and positioning a code area to which the abnormal performance data belongs in the to-be-analyzed program; and generating an analysis result of the to-be-analyzed program based on the code area and the abnormal performance data. According to the method, the code area capable of being optimized can be positioned according to the intermediate representation of the to-be-analyzed program, the performance analysis efficiency and analysis accuracy of the to-be-analyzed program are improved, and a basis is provided for performance optimization of the to-be-analyzed program.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a program performance analysis method, apparatus, and electronic device. Background Technology

[0002] As software systems become increasingly complex, existing program performance analysis methods are no longer sufficient to meet optimization needs. Source code-level analysis is disconnected from the underlying execution due to the high optimization of the compiler, leading to distorted analysis results; binary-level analysis is plagued by issues such as lost symbol information and ambiguous control flow, making it difficult to accurately locate bottlenecks; although the compiler's intermediate representation (IR) provides a starting point for program performance analysis, there is currently a severe lack of relevant analysis methods.

[0003] Therefore, how to analyze program performance through intermediate representations has become a technical problem that the industry urgently needs to solve. Summary of the Invention

[0004] This application provides a program performance analysis method, apparatus, and electronic device to solve the technical problem of how to analyze program performance through intermediate representation in the prior art.

[0005] Firstly, this application provides a program performance analysis method, including: Obtain the intermediate representation of the program to be analyzed based on the compiler plugin; Based on the multi-dimensional performance characteristics of the intermediate representation, multiple performance data of the program to be analyzed are determined; Identify abnormal performance data among multiple performance data sets and locate the code region to which the abnormal performance data belongs in the program to be analyzed; The analysis results of the program to be analyzed are generated based on the code region and the abnormal performance data.

[0006] In some embodiments, the multi-dimensional performance characteristics include instruction-level characteristics, basic block-level characteristics, and function-level characteristics; determining multiple performance data of the program to be analyzed based on the multi-dimensional performance characteristics of the intermediate representation includes: Convert the intermediate data format into the target data format; Obtain the multi-dimensional performance characteristics of the intermediate representation of the target data format; Based on the aforementioned multi-dimensional performance characteristics, multiple performance data are determined; the performance data includes the instruction execution efficiency, memory access data, and control flow data of the program to be analyzed.

[0007] In some embodiments, obtaining the multi-dimensional performance characteristics of the intermediate representation of the target data format includes: The instruction-level features are determined based on at least one of the distribution frequency of each type of instruction in the intermediate representation, operand type, and inter-instruction dependencies. The program to be analyzed is divided into multiple basic blocks, and the basic block-level features are determined based on at least one of the size of the basic block, the execution frequency, and the control flow transfer probability between the basic blocks. The function-level characteristics are determined based on at least one of the following: function call frequency, recursion depth, parameter passing method, number of local variables, and instruction execution complexity.

[0008] In some embodiments, determining the basic block-level characteristics based on at least one of the basic block size, execution frequency, and control flow transfer probability between basic blocks includes: Based on the control flow graph of the intermediate representation, the program to be analyzed is divided into multiple basic blocks, each of which includes a set of instructions. The size of the basic block is determined based on the number of instructions or bytes in the basic block; The execution frequency of the basic block is predicted based on the entry point of the program to be analyzed and the control flow graph. Predict the control flow transition probability between the basic blocks based on the positional relationship between the basic blocks in the control flow graph; The size of the basic block, the execution frequency, and the control flow transfer probability are used as at least one of the basic block-level features.

[0009] In some embodiments, determining the function-level characteristics based on at least one of the function call frequency, recursion depth, parameter passing method, number of local variables, and instruction execution complexity of the intermediate representation includes: Based on the function definitions and function call relationships in the intermediate representation, a function call graph of the program to be analyzed is constructed; Based on the function call graph, determine at least one of the following factors during the execution of the program to be analyzed: the function call frequency, the recursion depth, the parameter passing method, the number of local variables, and the instruction execution complexity. The function-level feature is defined as at least one of the following: call frequency, recursion depth, parameter passing method, number of local variables, and instruction execution complexity.

[0010] In some embodiments, determining multiple performance data of the program to be analyzed based on the multi-dimensional performance characteristics of the intermediate representation includes: The average execution cycle of the program to be analyzed is determined based on the instruction-level characteristics; the average execution cycle is used to characterize the instruction execution efficiency of the program to be analyzed. The memory access data is obtained based on the instruction-level features of memory access instructions and the basic block-level features in the instruction-level features. The control flow data is obtained based on the basic block-level features and the function-level features.

[0011] In some embodiments, determining the average execution cycle of the program to be analyzed based on the instruction-level characteristics includes: The average execution cycle of each type of instruction in the intermediate representation is determined based on the instruction-level characteristics. The average execution cycle of the program to be analyzed is determined based on the average execution cycle and the distribution frequency of each type of instruction.

[0012] In some embodiments, identifying anomalous performance data among the plurality of performance data and locating the code region to which the anomalous performance data belongs in the program to be analyzed includes: The performance data is matched with a preset data range to obtain a matching result; If the matching result is a mismatch, the performance data that does not match the data range will be regarded as the abnormal performance data. Obtain the abnormal instruction corresponding to the abnormal performance data in the program to be analyzed; Determine the exception base block to which the exception instruction belongs and the exception function to which the exception base block belongs; The code region in the program to be analyzed is determined based on the exception function.

[0013] Secondly, this application provides a program performance analysis apparatus, comprising: The acquisition module is used to obtain the intermediate representation of the program to be analyzed based on the compiler plugin; The determination module is used to determine multiple performance data of the program to be analyzed based on the multi-dimensional performance characteristics of the intermediate representation; The positioning module is used to identify abnormal performance data among multiple performance data and locate the code region to which the abnormal performance data belongs in the program to be analyzed; The analysis module is used to generate analysis results for the program to be analyzed based on the code region and the abnormal performance data.

[0014] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to implement the above-described method when executing the program through the computer program.

[0015] The program performance analysis method, apparatus, and electronic device provided in this application directly intercept the intermediate representation of the program to be analyzed through a compiler plugin and analyze the performance of the program to be analyzed by analyzing the intermediate representation. This effectively solves the technical difficulties of source code-level analysis being distorted due to compiler optimization and binary-level analysis being difficult to locate due to the loss of symbol information. By determining multiple performance data of the program to be analyzed through the multi-dimensional performance characteristics of the intermediate representation, identifying abnormal performance data among the multiple performance data, and locating the code region to which the abnormal performance data belongs, the analysis results of the program to be analyzed are generated. This allows the code region to be optimized to be located in the early stages of software development, improving the efficiency and accuracy of performance analysis of the program to be analyzed and providing a basis for performance optimization of the program to be analyzed. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is one of the flowcharts illustrating the program performance analysis method provided in the embodiments of this application.

[0018] Figure 2 This is a second flowchart illustrating the program performance analysis method provided in this application embodiment.

[0019] Figure 3 This is the third flowchart illustrating the program performance analysis method provided in this application embodiment.

[0020] Figure 4 The fourth flowchart illustrates the program performance analysis method provided in this application embodiment.

[0021] Figure 5 This is a schematic diagram of the structure of the program performance analysis device provided in an embodiment of this application.

[0022] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] It should be noted that the terms "first," "second," etc., used in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0025] The program performance analysis method provided in this application is applicable to terminals. Terminals can be various electronic devices with displays and support web browsing, including but not limited to servers, smartphones, tablets, laptops, and desktop computers.

[0026] Figure 1 This is one of the flowcharts illustrating the program performance analysis method provided in the embodiments of this application, such as... Figure 1 As shown, the method includes steps 110, 120, 130, and 140. These method steps are merely one possible implementation of this application.

[0027] Step 110: Obtain the intermediate representation of the program to be analyzed based on the compiler plugin.

[0028] Specifically, the execution subject of the program performance analysis method provided in this application embodiment is a program performance analysis device, which can be a hardware device independently set in the terminal or a software program running in the terminal.

[0029] Compiler plugins are software modules that can be integrated into a compiler to access, intercept, or modify the intermediate representation of the program being analyzed during the compilation process.

[0030] The program to be analyzed is a software package or source code that is prepared for performance evaluation and bottleneck identification.

[0031] Intermediate representation is an abstract data structure that lies between the source code of the program to be analyzed and the target machine code, generated during the compilation process.

[0032] This application's embodiments utilize a compiler plugin to intercept the IR of the program to be analyzed during the compilation process. A custom compiler plugin can be integrated into a compiler (such as Clang / LLVM) to automatically intercept and export the complete IR of the program to be analyzed during the intermediate stage of compilation.

[0033] Figure 2 The second flowchart illustrating the program performance analysis method provided in this application embodiment is as follows: Figure 2 As shown, corresponding plugin interfaces can be developed for different programming languages ​​and compilers, such as GCC, Clang (C / C++ compiler), and JVM (Java Virtual Machine). Taking the Clang compiler as an example, by writing a compiler plugin based on the LLVM framework, and utilizing its comprehensive IR generation and manipulation interfaces, complete IR code can be obtained in the intermediate stage of program compilation. This ensures that the plugin can be seamlessly integrated with the compiler without affecting the normal compilation process, and can handle large-scale code projects.

[0034] Syntax and semantic checks can be performed on the acquired instruction references (IRs) to ensure their integrity and compliance. Since IRs generated by compilers under different optimization levels or compilation options may differ, and may even contain potential syntax errors or incomplete semantic information, this embodiment performs IR syntax verification based on the BNF paradigm. Based on the syntax rules and semantic specifications provided by the compiler, the IR is checked line by line, including instruction format verification, operand type checking, and control flow structure integrity verification. For errors or non-compliance in the acquired IR, detailed error information is recorded, and repairs or prompts are generated and sent to the relevant personnel's terminals to prompt corrections. The IR can also be standardized through format conversion.

[0035] Step 120: Determine multiple performance data of the program to be analyzed based on the multi-dimensional performance characteristics of the intermediate representation.

[0036] Specifically, multi-dimensional performance characteristics are a set of feature vectors extracted from multiple program structure levels such as instructions, basic blocks, and functions, which can collectively reflect the potential runtime characteristics of the program to be analyzed.

[0037] Performance data is calculated based on multi-dimensional performance characteristics and is used to quantify specific indicators of the performance of the program under analysis in terms of instruction execution efficiency, memory access, and control flow.

[0038] The acquired IR is analyzed in depth to extract multi-dimensional performance characteristics, and multiple performance data of the program to be analyzed are calculated based on these characteristics.

[0039] Step 130: Identify abnormal performance data among multiple performance data sets and locate the code region to which the abnormal performance data belongs in the program to be analyzed.

[0040] Specifically, abnormal performance data is performance data that indicates potential performance bottlenecks in the program being analyzed. The presence of abnormal performance data indicates that the code of the program being analyzed has room for optimization.

[0041] The code region is the specific code segment in the program to be analyzed that has been located and confirmed to cause abnormal performance data, such as functions, basic blocks, or loops.

[0042] The data range can be preset, and each performance data point can be compared with the preset data range. Performance data that does not conform to the data range is regarded as abnormal performance data. Using the structural information built into IR (such as code line number, function affiliation, etc.), the abnormal performance data can be traced upwards step by step to accurately locate the code area in the program to be analyzed.

[0043] The preset data range can be set based on performance thresholds or historical performance baselines. Performance thresholds can be set based on the performance characteristics of the target processor architecture of the program being analyzed, industry standards, and empirical data. Historical performance baselines can be obtained by analyzing similar programs with known good performance or different historical versions of the program being analyzed. The target processor architecture refers to the specific design and instruction set architecture of the central processing unit (CPU) that the program being analyzed will ultimately run on. It defines which instructions the CPU can understand and execute, and how efficiently it executes each instruction.

[0044] Step 140: Generate analysis results for the program to be analyzed based on code regions and abnormal performance data.

[0045] Specifically, the analysis results are a structured report that integrates the code region where the performance bottleneck of the program under analysis is located, related abnormal performance data and their causes, aiming to provide guidance for the optimization of the program under analysis.

[0046] After locating the code region, analysis results are generated based on relevant abnormal performance data and the cause analysis of system-generated anomalies. A results report can be generated based on the analysis results and sent to the terminals of relevant personnel; alternatively, a feasible optimization plan for the analyzed program can be generated based on the analysis results.

[0047] The program performance analysis method provided in this application directly intercepts the intermediate representation of the program to be analyzed through a compiler plugin and analyzes the performance of the program by analyzing the intermediate representation. This effectively solves the technical difficulties of source code-level analysis being distorted due to compiler optimization and binary-level analysis being difficult to locate due to the loss of symbol information. By determining multiple performance data of the program to be analyzed through the multi-dimensional performance characteristics of the intermediate representation, identifying abnormal performance data among the multiple performance data, and locating the code region to which the abnormal performance data belongs, the analysis results of the program to be analyzed are generated. This allows the code region to be optimized to be located in the early stages of software development, improving the efficiency and accuracy of performance analysis of the program to be analyzed and providing a basis for performance optimization of the program to be analyzed.

[0048] It should be noted that each implementation method of this application can be freely combined, rearranged, or executed individually, and does not need to rely on or depend on a fixed execution order.

[0049] In some embodiments, the multi-dimensional performance characteristics include instruction-level characteristics, basic block-level characteristics, and function-level characteristics; step 120 includes: Convert the intermediate data format to the target data format; Obtain multi-dimensional performance characteristics of the intermediate representation of the target data format; Multiple performance data points are determined based on multi-dimensional performance characteristics; these performance data include instruction execution efficiency, memory access data, and control flow data of the program to be analyzed.

[0050] Specifically, instruction-level characteristics are data that characterize the features of a single instruction in the program to be analyzed, such as the instruction type, operand format, and execution frequency.

[0051] Basic block-level features are data that characterize the properties of basic blocks (i.e., sequentially executed instruction sequences) in the program to be analyzed, such as the size of the basic block, execution frequency, and flow transition probability.

[0052] Function-level features are data that characterize the overall properties of function units in the program being analyzed, such as function call frequency, recursion depth, and parameter passing methods.

[0053] The target data format is a unified and standardized internal IR format designed to eliminate differences between different compiler versions or dialects.

[0054] Different versions of LLVM IR may differ in instruction sets, data type representations, and / or attribute naming. Therefore, IRs of various versions and dialects can be standardized to convert the IR data format into a unified internal representation format (i.e., target data format), thereby eliminating the differences caused by different compiler versions or dialects.

[0055] Standardization processes can include operations such as unifying instruction names, standardizing data type definitions, and converting attribute formats.

[0056] Subsequent analysis can be conducted based on a unified IR format, such as obtaining multi-dimensional performance characteristics of the intermediate representation of the target data format; determining multiple performance data based on multi-dimensional performance characteristics and performing program performance analysis can improve the accuracy and consistency of program performance analysis.

[0057] Instruction execution efficiency is a performance metric used to measure how fast a program executes at the instruction level.

[0058] Memory access data is a set of metrics used to evaluate the efficiency of the interaction between the program being analyzed and the memory system, including estimated cache hit rate, memory bandwidth requirements, and data locality.

[0059] Control flow data are metrics used to quantify the performance overhead of a program caused by logic such as branching, jumping, and function calls, including branch prediction failure rate and total cost of function calls.

[0060] The program performance analysis method provided in this application unifies the data format of the IR to the target data format, enabling accurate extraction and analysis of multi-dimensional performance characteristics (instruction level, basic block level, and function level) across compilers, thereby improving the accuracy and consistency of program performance evaluation.

[0061] In some embodiments, obtaining multi-dimensional performance characteristics of the intermediate representation of the target data format includes: The instruction-level characteristics are determined based on at least one of the following: the distribution frequency of each type of instruction, operand type, and inter-instruction dependencies, according to the intermediate representation. The program to be analyzed is divided into multiple basic blocks, and basic block-level features are determined based on at least one of the basic block size, execution frequency and control flow transfer probability between basic blocks. Based on intermediate representation, at least one of the following function-level characteristics is determined: function call frequency, recursion depth, parameter passing method, number of local variables, and instruction execution complexity.

[0062] The basic block-level features are determined based on at least one of the following: basic block size, execution frequency, and control flow transfer probability between basic blocks, including: The control flow graph based on intermediate representation divides the program to be analyzed into multiple basic blocks, each of which includes a set of instructions. The size of a basic block is determined based on the number of instructions or bytes in the basic block; Predict the execution frequency of basic blocks based on the entry point and control flow graph of the program to be analyzed; Predict the control flow transition probability between basic blocks based on the positional relationship between basic blocks in the control flow graph; Use at least one of the following as basic block-level features: basic block size, execution frequency, and control flow transfer probability.

[0063] Based on intermediate representation, at least one of the following function-level characteristics is determined: function call frequency, recursion depth, parameter passing method, number of local variables, and instruction execution complexity: Based on the function definitions and function call relationships in the intermediate representation, a function call graph of the program to be analyzed is constructed; Based on the function call graph, determine at least one of the following factors during the execution of the program to be analyzed: function call frequency, recursion depth, parameter passing method, number of local variables, and instruction execution complexity. At least one of the following can be used as a function-level feature: call frequency, recursion depth, parameter passing method, number of local variables, and instruction execution complexity.

[0064] Specifically, instruction types can include arithmetic instructions (such as instructions involving addition, subtraction, multiplication, and division), memory access instructions (such as instructions involving loading and storing), and control transfer instructions (such as instructions involving conditional jumps, unconditional jumps, function calls, and returns).

[0065] Figure 3 The third flowchart illustrating the program performance analysis method provided in this application embodiment is as follows: Figure 3 As shown, the instruction-level performance feature vector can be formed by at least one of the following factors in the instruction IR: the frequency of each instruction type (e.g., the number of times and percentage of each instruction type), operand type (e.g., whether the operand is an immediate value, a register, or a memory address), and inter-instruction dependencies (e.g., data dependency or control dependency). This allows us to obtain the instruction-level features of the program under analysis. Instruction-level features can reflect the efficiency and potential optimization space of the program under analysis in terms of instruction execution. For example, excessive memory access instructions may indicate data locality problems, and frequent conditional jump instructions may lead to branch prediction failures.

[0066] Pattern matching and static analysis algorithms can be used to scan every instruction in the IR code and record the occurrence count of each type of instruction.

[0067] For example, for arithmetic instructions, count the number of instructions for each type of operation; for memory access instructions, analyze their access mode (such as sequential access, random access) and the data type accessed (such as scalar, array, structure).

[0068] The basic block-level performance feature vector is formed by taking at least one of the following factors: the size of each basic block of the program to be analyzed (such as the number of instructions or bytes contained therein), the estimated execution frequency, and the control flow transfer probability between basic blocks. This results in the basic block-level features of the program to be analyzed.

[0069] A control flow graph (CFG) is a directed graph that represents all possible paths during the execution of a program being analyzed. The nodes in the graph are called basic blocks. By analyzing the CFG of an IR program, the program being analyzed can be divided into multiple basic blocks.

[0070] Each basic block consists of a sequence of instructions executed sequentially without interruption; control flow transfers are only possible at the end of the basic block. The size of each basic block is calculated based on the number of instructions or bytes within it, and the types and number of instructions it contains are analyzed. Based on the entry point of the program under analysis and the structure of the CFG (Current Flow Group), static analysis methods (such as program counter-based simulated execution or path analysis-based probabilistic estimation) are used to predict the execution frequency of each basic block. Simultaneously, the control flow transfer probabilities between basic blocks are calculated; the control flow transfer probability is the likelihood of transferring from one basic block to another. These characteristics help assess the control flow complexity and execution efficiency of the basic blocks in the program under analysis. For example, larger basic blocks may affect instruction cache utilization, and complex control flow transfers may increase the difficulty of branch prediction.

[0071] Analyze the function structure of the entire program under analysis, and determine the function-level characteristics of the program based on at least one of the following: function call frequency (i.e., how often the function is called), recursion depth, parameter passing method (such as pass-by-value, pass-by-reference, or register passing), number of local variables (and the stack space they occupy), storage requirements, and instruction execution complexity.

[0072] By analyzing the function definitions and function call relationships in the Interpreter Relationship (IR), a function call graph is constructed. A function call graph is a directed graph representing the call and called relationships between functions in the program being analyzed. By analyzing this function call graph, a series of function-level features can be determined.

[0073] By analyzing the in-degree of nodes in the function call graph, the expected number of calls to each function during the entire execution of the program under analysis can be counted, and the call frequency can be calculated. By analyzing the recursive call structure of functions, i.e., by detecting loops in the function call graph, the recursive calls of functions and their maximum recursion depth can be determined. The recursion depth is the maximum nested level of a recursive function continuously calling itself until it returns. By analyzing the parameter list in the function definition, the parameter passing method can be determined, thereby examining the impact of the parameter passing method on the performance of the program under analysis. For example, pass-by-value may lead to data copying overhead, while pass-by-reference may introduce aliasing issues. By analyzing the variable declarations inside the function, the number of local variables can be counted, thereby assessing its requirements for register allocation and stack space. By analyzing the corresponding CFG of the function, its instruction execution complexity (such as loop nesting depth, number of conditional checks, etc.) can be calculated. These characteristics comprehensively reflect the performance characteristics of functions, providing a reference for function-level optimization, such as optimizing the parameter passing method of frequently called functions, reducing the number of local variables in functions, and reducing the instruction execution complexity of functions.

[0074] One or more of the following factors—call frequency, recursion depth, parameter passing method, number of local variables, and instruction execution complexity—can be used as function-level characteristics of the program to be analyzed.

[0075] The program performance analysis method provided in this application provides rich and accurate basic data for performance data quantification calculation by acquiring characteristics at the instruction level, basic block level, and function level, thereby improving the depth and reliability of the final analysis results.

[0076] In some embodiments, step 120 includes: The average execution cycle of the program to be analyzed is determined based on instruction-level characteristics; the average execution cycle is used to characterize the instruction execution efficiency of the program to be analyzed. Memory access data is obtained based on the instruction-level characteristics and basic block-level characteristics of memory access instructions in the instruction-level characteristics. Control flow data is obtained based on basic block-level features and function-level features.

[0077] Among them, determining the average execution cycle of the program to be analyzed based on instruction-level characteristics includes: The average execution cycle of each type of instruction in the intermediate representation is determined based on instruction-level characteristics; The average execution cycle of the program to be analyzed is determined based on the average execution cycle and distribution frequency of each type of instruction.

[0078] Specifically, Figure 4 The fourth flowchart illustrating the program performance analysis method provided in this application embodiment is as follows: Figure 4 As shown, the average execution cycle per instruction (CPI) of the program under analysis is calculated based on the extracted instruction-level features. The average execution cycle per instruction is an indicator that represents the average number of clock cycles required to execute a single instruction; a lower value indicates higher efficiency. This CPI is used to characterize the instruction execution efficiency of the program under analysis.

[0079] It can load instruction performance models for the target processor architecture, which can calculate the average CPI of various instructions using factors such as instruction type, operand type, and dependencies between instructions.

[0080] By analyzing instruction-level characteristics, the distribution frequency of each type of instruction can be obtained. Using the weighted average formula, the average CPI of each type of instruction is multiplied by its distribution frequency and then summed to calculate the weighted average CPI of the program to be analyzed. This value reflects the overall efficiency of the program to be analyzed at the instruction execution level, because instructions that are executed more frequently will have a greater impact on the final result.

[0081] The weighted average formula is shown below: ; in. The weighted average CPI of the program to be analyzed. For instruction type The distribution frequency, For instruction type Average CPI under the target processor architecture n The number of instruction types.

[0082] Memory access data is calculated using the instruction-level and basic block characteristics of memory access instructions. This data includes estimated cache hit rates, memory bandwidth requirements, and data locality.

[0083] The static analysis method of this application is a technique for inferring the behavior and performance characteristics of a program by analyzing its intermediate representation without actually running the program to be analyzed.

[0084] Based on the data access patterns and caching models of the program under analysis (such as models of L1 cache, L2 cache, and memory hierarchy), static analysis methods (such as historical data fitting based on access patterns and prediction based on data reuse analysis) are used to estimate the hit probability (i.e., cache hit rate) of memory accesses in each level of cache. Based on the distribution frequency of memory access instructions and the size and type of accessed data, the runtime bandwidth requirements of the program under analysis are estimated. Furthermore, data locality metrics, such as spatial locality and temporal locality metrics, can be calculated to evaluate the impact of the program's data layout on cache performance by analyzing the proximity and repeated access patterns of data accesses.

[0085] Cache hit rate H The calculation formula is as follows: ; in, For basic blocks The locality coefficient, For the number of visits, This represents the total number of times a memory access request was successfully found in the cache. This represents the total number of memory access requests issued by the program being analyzed. This number can be determined by the execution frequency of basic blocks that include memory access instructions. L This represents the total number of basic blocks.

[0086] Control flow data, including branch prediction failure rate and total function call cost, is calculated using basic block-level and function-level features. Based on the control flow transition probabilities between basic blocks and the target processor's branch prediction cost model (such as static prediction, dynamic prediction, or history-based prediction models), the prediction failure probability of branch instructions in the program under analysis is estimated. Taking into account factors such as the execution cycle of function call instructions, the overhead of parameter passing and return value processing, and the cost of stack frame creation and destruction, the impact of function calls on the performance of the program under analysis is evaluated, yielding the total function call cost. By analyzing the CFG structure of the program under analysis, complexity measurement methods (such as cyclomatic complexity algorithms) are used to quantify the complexity of the control flow, providing a basis for optimizing the control flow structure.

[0087] Branch prediction failure rate The estimation formula is as follows: ; in, For the set of all branch instructions, For branches The module for calculating the probability performance index of the execution. branch instructions b The estimated total number of executions, branch instructions b The estimated number of correct predictions.

[0088] The program performance analysis method provided in this application transforms abstract program features into quantifiable performance indicators, enabling the performance status of the program to be analyzed to be presented in an intuitive data form, thereby improving the measurability and analyzability of program performance.

[0089] In some embodiments, step 130 includes: The performance data is matched with a preset data range to obtain the matching results; If the matching result is not a match, the performance data that does not match the data range will be regarded as abnormal performance data; Obtain the abnormal instructions in the program to be analyzed corresponding to the abnormal performance data; Determine the exception block to which the exception instruction belongs and the exception function to which the exception block belongs; The code region in the program to be analyzed is determined based on the exception function.

[0090] Specifically, the calculated performance data is matched against a preset data range to identify abnormal performance data that exceeds a reasonable range. For example, if the CPI value is higher than a threshold, the performance data is marked as abnormal.

[0091] Different categories of performance data can correspond to different data ranges, and each category of performance data is matched with its corresponding data range. The degree of deviation of each category of performance data from its corresponding data range can be calculated to determine the degree of anomalousness of abnormal performance data. Priorities are defined based on the degree of anomalousness; the higher the degree of anomalousness, the higher the priority, and the more attention is required.

[0092] By combining the structural information and call relationships in the IR, we can trace back step by step from the underlying instruction execution level to accurately locate the code region that causes the performance bottleneck.

[0093] For the identified abnormal performance data, analyze the corresponding instruction type and distribution location to pinpoint specific functions, basic blocks, or instruction sequences.

[0094] The composition of the abnormal performance data can be analyzed to pinpoint one or more abnormal instructions that contribute the most to the outlier. For example, if the CPI is too high, the instruction with the longest execution cycle and the most frequent execution can be identified. Using the inherent structural information in the IR, the abnormal basic block to which the abnormal instruction belongs can be determined, and further, the abnormal function to which the abnormal basic block belongs can be identified. This abnormal function, or its more specific instruction sequence (such as a loop), can then be identified as the code region causing the performance bottleneck.

[0095] If the abnormal performance data is memory access data, analyze its corresponding memory access patterns and data layout to ultimately pinpoint the data structure or access code causing cache misses or memory bandwidth bottlenecks. If the abnormal performance data is control flow data, analyze the reasons for branch prediction failures or excessive function call overhead to locate complex conditional logic or frequent function call locations, thus identifying the relevant code region. Simultaneously, analyze the causes of performance bottlenecks, such as excessive algorithm complexity, unnecessary memory operations, frequent function call overhead, unreasonable data layout, or branch prediction difficulties. In-depth analysis of the causes provides specific directions and suggestions for subsequent performance optimization.

[0096] The program performance analysis method provided in this application compares performance data with a preset range and uses the structural information of the IR to trace back step by step, establishing a clear location path from abnormal indicators to the source code area, improving the automation and accuracy of performance bottleneck location, and enabling quick identification of the root cause of the problem.

[0097] The program performance analysis apparatus provided in the embodiments of this application is described below. The program performance analysis apparatus described below and the program performance analysis method described above can be referred to in correspondence.

[0098] Figure 5 This is a schematic diagram of the structure of the program performance analysis device provided in the embodiments of this application, as shown below. Figure 5As shown, the device includes an acquisition module 510, a determination module 520, a positioning module 530, and an analysis module 540.

[0099] The acquisition module is used to obtain the intermediate representation of the program to be analyzed based on the compiler plugin; The determination module is used to determine multiple performance data of the program to be analyzed based on the multi-dimensional performance characteristics of the intermediate representation; The localization module is used to identify abnormal performance data among multiple performance data and locate the code region to which the abnormal performance data belongs in the program to be analyzed. The analysis module is used to generate analysis results for the program under analysis based on code regions and abnormal performance data.

[0100] Specifically, according to the embodiments of this application, any and multiple modules among the acquisition module, determination module, positioning module and analysis module can be combined into one module, or any one of them can be split into multiple modules.

[0101] Alternatively, at least some of the functionality of one or more of these modules can be combined with at least some of the functionality of other modules and implemented in a single module.

[0102] According to embodiments of this application, at least one of the acquisition module, determination module, positioning module, and analysis module can be at least partially implemented as hardware circuitry, such as a Field Programmable Gate Array (FPGA), Programmable Logic Array (PLA), System-on-a-Chip, System-on-a-Substrate, System-on-Package, Application Specific Integrated Circuit (ASIC), or any other reasonable means of integrating or packaging the circuitry, or implemented in hardware or firmware, or in any one of the three implementation methods of software, hardware, and firmware, or in a suitable combination of any of them.

[0103] Alternatively, at least one of the acquisition module, determination module, location module, and analysis module can be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0104] In some embodiments, the determining module is specifically used for: Convert the intermediate data format into the target data format; Obtain the multi-dimensional performance characteristics of the intermediate representation of the target data format; Based on the aforementioned multi-dimensional performance characteristics, multiple performance data are determined; the performance data includes the instruction execution efficiency, memory access data, and control flow data of the program to be analyzed.

[0105] In some embodiments, obtaining the multi-dimensional performance characteristics of the intermediate representation of the target data format includes: The instruction-level features are determined based on at least one of the distribution frequency of each type of instruction in the intermediate representation, operand type, and inter-instruction dependencies. The program to be analyzed is divided into multiple basic blocks, and the basic block-level features are determined based on at least one of the size of the basic block, the execution frequency, and the control flow transfer probability between the basic blocks. The function-level characteristics are determined based on at least one of the following: function call frequency, recursion depth, parameter passing method, number of local variables, and instruction execution complexity.

[0106] In some embodiments, determining the basic block-level characteristics based on at least one of the basic block size, execution frequency, and control flow transfer probability between basic blocks includes: Based on the control flow graph of the intermediate representation, the program to be analyzed is divided into multiple basic blocks, each of which includes a set of instructions. The size of the basic block is determined based on the number of instructions or bytes in the basic block; The execution frequency of the basic block is predicted based on the entry point of the program to be analyzed and the control flow graph. Predict the control flow transition probability between the basic blocks based on the positional relationship between the basic blocks in the control flow graph; The size of the basic block, the execution frequency, and the control flow transfer probability are used as at least one of the basic block-level features.

[0107] In some embodiments, determining the function-level characteristics based on at least one of the function call frequency, recursion depth, parameter passing method, number of local variables, and instruction execution complexity of the intermediate representation includes: Based on the function definitions and function call relationships in the intermediate representation, a function call graph of the program to be analyzed is constructed; Based on the function call graph, determine at least one of the following factors during the execution of the program to be analyzed: the function call frequency, the recursion depth, the parameter passing method, the number of local variables, and the instruction execution complexity. The function-level feature is defined as at least one of the following: call frequency, recursion depth, parameter passing method, number of local variables, and instruction execution complexity.

[0108] In some embodiments, the determining module is specifically used for: The average execution cycle of the program to be analyzed is determined based on the instruction-level characteristics; the average execution cycle is used to characterize the instruction execution efficiency of the program to be analyzed. The memory access data is obtained based on the instruction-level features of memory access instructions and the basic block-level features in the instruction-level features. The control flow data is obtained based on the basic block-level features and the function-level features.

[0109] In some embodiments, determining the average execution cycle of the program to be analyzed based on the instruction-level characteristics includes: The average execution cycle of each type of instruction in the intermediate representation is determined based on the instruction-level characteristics. The average execution cycle of the program to be analyzed is determined based on the average execution cycle and the distribution frequency of each type of instruction.

[0110] In some embodiments, the positioning module is specifically used for: The performance data is matched with a preset data range to obtain a matching result; If the matching result is a mismatch, the performance data that does not match the data range will be regarded as the abnormal performance data. Obtain the abnormal instruction corresponding to the abnormal performance data in the program to be analyzed; Determine the exception base block to which the exception instruction belongs and the exception function to which the exception base block belongs; The code region in the program to be analyzed is determined based on the exception function.

[0111] It should be noted that the program performance analysis device provided in this application embodiment can implement all the method steps implemented in the above program performance analysis method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0112] Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application, such as... Figure 6 As shown, the electronic device may include a processor 610, a communication interface 620, a memory 630, and a communication bus 640, wherein the processor 610, the communication interface 620, and the memory 630 communicate with each other through the communication bus 640. The processor 610 can call the computer program in the memory 630 to execute the above-described method.

[0113] Furthermore, the logical instructions in the aforementioned memory can be implemented as software functional modules and sold or used as independent products, and can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0114] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the methods provided in the above embodiments.

[0115] On the other hand, embodiments of this application also provide a processor-readable storage medium storing a computer program for causing the processor to execute the methods provided in the above embodiments.

[0116] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0117] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0118] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0119] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method of program performance analysis, characterized by, The method comprises: obtaining an intermediate representation of a program to be analyzed based on a compiler plug-in; determining a plurality of performance data of the program to be analyzed based on multi-dimensional performance characteristics of the intermediate representation; identifying abnormal performance data in the plurality of performance data and locating a code region to which the abnormal performance data belongs in the program to be analyzed; generating an analysis result of the program to be analyzed based on the code region and the abnormal performance data.

2. The program performance analysis method according to claim 1, characterized by, The determining of the plurality of performance data of the program to be analyzed based on the multi-dimensional performance characteristics of the intermediate representation comprises: converting a data format of the intermediate representation into a target data format; obtaining the multi-dimensional performance characteristics of the intermediate representation in the target data format; determining a plurality of performance data based on the multi-dimensional performance characteristics; the performance data comprises instruction execution efficiency, memory access data and control flow data of the program to be analyzed.

3. The program performance analysis method according to claim 2, characterized by, The multi-dimensional performance characteristics comprise instruction level characteristics, basic block level characteristics and function level characteristics; the obtaining of the multi-dimensional performance characteristics of the intermediate representation in the target data format comprises: determining the instruction level characteristics based on at least one of a distribution frequency of each type of instruction, an operand type and a dependency relationship between instructions of the intermediate representation; dividing the program to be analyzed into a plurality of basic blocks, and determining the basic block level characteristics based on at least one of a size, an execution frequency and a control flow transition probability between basic blocks of the basic blocks; determining the function level characteristics based on at least one of a call frequency, a recursion depth, a parameter passing mode, a number of local variables and an instruction execution complexity of a function of the intermediate representation.

4. The program performance analysis method according to claim 3, characterized by, The determining of the basic block level characteristics based on at least one of the size, the execution frequency and the control flow transition probability between basic blocks comprises: dividing the program to be analyzed into a plurality of basic blocks based on a control flow graph of the intermediate representation, each of the basic blocks comprising a group of instructions; determining the size of the basic block based on a number of instructions or a number of bytes of the basic block; predicting the execution frequency of the basic block based on an entry point of the program to be analyzed and the control flow graph; predicting the control flow transition probability between the basic blocks based on a positional relationship between the basic blocks in the control flow graph; taking at least one of the size, the execution frequency and the control flow transition probability of the basic block as the basic block level characteristics.

5. The program performance analysis method according to claim 3, characterized by, The determining of the function level characteristics based on at least one of the call frequency, the recursion depth, the parameter passing mode, the number of local variables and the instruction execution complexity of the function of the intermediate representation comprises: constructing a function call graph of the program to be analyzed based on function definitions and function call relationships in the intermediate representation; determining at least one of the call frequency, the recursion depth, the parameter passing mode, the number of local variables and the instruction execution complexity of the function in the execution process of the program to be analyzed based on the function call graph; taking at least one of the call frequency, the recursion depth, the parameter passing mode, the number of local variables and the instruction execution complexity as the function level characteristics.

6. The program performance analysis method according to claim 3, characterized by, The multi-dimension performance feature based on the intermediate representation determines a plurality of performance data of the program to be analyzed, including: determining an average execution cycle of the program to be analyzed based on the instruction level feature; the average execution cycle is used to represent the instruction execution efficiency of the program to be analyzed; obtaining the memory access data based on the instruction level feature of the memory access instruction in the instruction level feature and the basic block level feature; obtaining the control flow data based on the basic block level feature and the function level feature.

7. The program performance analysis method according to claim 6, characterized by, The determining of the average execution cycle of the program to be analyzed based on the instruction level feature includes: determining an average execution cycle of each type of instruction in the intermediate representation based on the instruction level feature; determining the average execution cycle of the program to be analyzed based on the average execution cycle of each type of instruction and the distribution frequency.

8. The program performance analysis method according to claim 3, characterized by, The identifying of the abnormal performance data in the plurality of performance data and the locating of the code region to which the abnormal performance data belongs in the program to be analyzed includes: matching the performance data with a preset data range to obtain a matching result; in a case that the matching result is not matched, taking the performance data not matched with the data range as the abnormal performance data; obtaining an abnormal instruction corresponding to the abnormal performance data in the program to be analyzed; determining an abnormal basic block to which the abnormal instruction belongs and an abnormal function to which the abnormal basic block belongs; determining the code region in the program to be analyzed based on the abnormal function.

9. A program performance analysis apparatus characterized by comprising: including: an obtaining module configured to obtain an intermediate representation of a program to be analyzed based on a compiler plug-in; a determining module configured to determine a plurality of performance data of the program to be analyzed based on multi-dimension performance features of the intermediate representation; a locating module configured to identify abnormal performance data in the plurality of performance data and locate a code region to which the abnormal performance data belongs in the program to be analyzed; an analyzing module configured to generate an analysis result of the program to be analyzed based on the code region and the abnormal performance data.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the program performance analysis method of any one of claims 1 to 8 through the computer program.

Images