Software performance defect mining method based on cross-architecture comparison

Abstract

The invention provides a software performance defect mining method based on cross-architecture comparison, and relates to the technical field of computer software, the method comprises the following steps: when a test set of to-be-detected software runs on a cross-CPU architecture, respectively acquiring corresponding performance data, and taking the ratio of the performance data as a to-be-detected performance data point, calling an auto-encoder to detect an abnormal test case; when the abnormal test case runs in the cross-CPU architecture, respectively collecting corresponding multi-dimensional performance data, and executing cross-CPU architecture function matching in the cross-architecture to obtain a successful matching function; and when the specific value of the clock cycle number of the successful matching function on the cross-CPU architecture is greater than a reference threshold value, determining that the successful matching function is a function causing the to-be-detected software to have performance defects. Through the software performance testing method and device, the problems that when software performance testing is carried out on a single framework, performance abnormity is judged by depending on manual setting of indexes, the cross-framework condition requirement cannot be met, and performance bottlenecks in the framework adaptation process are difficult to recognize are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software, and particularly to a method for discovering software performance defects based on cross-architecture comparison. Background Art

[0002] Discovering software performance defects refers to finding defects or bottlenecks that affect system performance during the development, testing, and execution of a software system. These performance defects usually manifest as excessive response time, high resource utilization, insufficient throughput, etc., which may affect user experience, system stability, or efficient utilization of resources. Discovering performance defects is not only about identifying whether the software functions properly, but also a crucial step in ensuring that the software can operate efficiently under actual load and various scenarios.

[0003] Software performance testing is an essential part of the software performance defect discovery process. It is a process of verifying whether the software meets the expected performance requirements of users, discovering potential performance bottlenecks in the software, analyzing performance problems, and providing performance optimization solutions. In the actual testing process, different testing methods can be adopted according to specific performance requirements and application fields to complete the verification of the software's performance requirements and application fields. In practical applications, software needs to be deployed and run on different CPU architecture platforms (such as X86, ARM64, RISC-V, etc.). The micro-architecture characteristics of each architecture lead to differences in the performance of application software. In order to improve the performance of the software on a certain architecture, discovering performance defects becomes crucial in the software optimization process. However, due to the differences between architectures, traditional performance testing methods cannot meet the requirements under cross-architecture conditions. The execution performance of the same software on different architectures is affected by hardware characteristics such as instruction sets, memory, I / O, cache levels, and sizes, making it complicated to directly conduct cross-architecture performance comparison and anomaly identification.

[0004] Currently, the industry usually conducts performance testing on a single architecture through performance benchmark testing tools to evaluate the performance of application software. However, such testing methods cannot accurately reflect cross-architecture performance differences and are difficult to effectively identify performance bottlenecks in the architecture adaptation process. In addition, existing methods usually rely on manually setting thresholds or metrics to judge performance anomalies, which has certain subjectivity and limitations, resulting in low accuracy. Summary of the Invention

[0005] The present invention provides a method for discovering software performance defects based on cross-architecture comparison, aiming to solve the problems that the existing performance testing methods only conduct performance testing on a single architecture, rely on manually setting thresholds or metrics to judge performance anomalies, cannot meet the requirements under cross-architecture conditions, and are difficult to effectively identify performance bottlenecks in the architecture adaptation process.

[0006] The present invention provides a method for discovering software performance defects based on cross-architecture comparison. The method includes the following steps: When the test set of the software to be detected is first run on the first CPU architecture and the second CPU architecture respectively, the first performance data and the second performance data are collected respectively; Taking the ratio of the first performance data and the second performance data as the performance data point to be detected, and calling an autoencoder to perform anomaly detection on the performance data point to be detected, obtaining an anomaly test case, wherein the autoencoder is adaptively optimized by a particle swarm optimization algorithm; When the anomaly test case is second-run on the first CPU architecture and the second CPU architecture respectively, the corresponding multi-dimensional performance data is collected respectively; Performing cross-architecture function matching based on the multi-dimensional performance data on the first CPU architecture and the second CPU architecture to obtain a successfully matched function; Determining the first number of clock cycles when the successfully matched function runs on the first CPU architecture and the second number of clock cycles when the successfully matched function runs on the second CPU architecture; When the ratio of the first number of clock cycles to the second number of clock cycles is greater than a benchmark threshold, determining that the successfully matched function is the function causing performance defects in the software to be detected.

[0007] In some embodiments, the performing cross-architecture function matching based on the multi-dimensional performance data on the first CPU architecture and the second CPU architecture to obtain a successfully matched function includes: Taking the target function in the multi-dimensional performance data collected on the first CPU architecture as a function index; Traversing each function to be matched in the multi-dimensional performance data collected on the second CPU architecture according to the function index; During the traversing process, when the function index and the function to be matched satisfy the following conditions, determining that the function to be matched is a successfully matched function: The function to be matched and the function index come from the same base class and command pattern; The similarity between the function name of the function index and the function name of the function to be matched reaches a preset threshold.

[0008] In some embodiments, the calculation process of the similarity between the function name of the function index and the function name of the function to be matched includes: Obtaining the first function name string of the function index and the second function name string of the function to be matched; Vectorizing the first function name string and the second function name string to obtain corresponding first string vector and second string vector; Determine the vector similarity between the first string vector and the second string vector, and use the vector similarity as the similarity between the function name of the function index and the function name of the function to be matched.

[0009] In some embodiments, the reference threshold is determined according to the SPEC CPU benchmark program. The process of determining the reference threshold includes: Execute the SPEC CPU benchmark program in the first CPU architecture and the second CPU architecture respectively, and collect the corresponding first performance test results and second performance test results during the execution process; Use the ratio of the first performance test result to the second performance test result as the reference threshold.

[0010] In some embodiments, after the corresponding multi-dimensional performance data is respectively collected, the method further includes: Perform cross-architecture function matching based on the multi-dimensional performance data in the first CPU architecture and the second CPU architecture to obtain functions that are not successfully matched. The functions that are not successfully matched are target functions that use the multi-dimensional performance data corresponding to the first CPU architecture as function indexes and do not match the functions to be matched in the multi-dimensional performance data corresponding to the second CPU architecture; Determine the resource occupancy data of the functions that are not successfully matched in the first CPU architecture. When the resource occupancy data reaches the set threshold, determine the functions that are not successfully matched as the functions that cause performance defects in the software to be detected.

[0011] In some embodiments, the method further includes: Perform performance optimization on the functions that cause performance defects in the software to be detected to obtain optimized functions; When the optimized functions run in the first CPU architecture and the second CPU architecture respectively, collect the corresponding running performance data; Determine the performance optimization result of the optimized functions according to the running performance data; When the performance optimization result indicates that the optimized functions are not the functions that cause performance defects in the software to be detected, update the functions with performance defects in the software to be detected according to the optimized functions.

[0012] The present invention also provides a software performance defect discovery device based on cross-architecture comparison. The device includes the following modules: A data acquisition module, configured to respectively collect first performance data and second performance data when the test set of the software to be detected is first run in the first CPU architecture and the second CPU architecture; Anomaly detection module, configured to use the ratio of the first performance data and the second performance data as a performance data point to be detected, and call an autoencoder to perform anomaly detection on the performance data point to be detected, so as to obtain an anomaly test case, where the autoencoder is adaptively optimized through a particle swarm optimization algorithm; The data acquisition module is further configured to respectively acquire corresponding multi-dimensional performance data when the anomaly test case runs for the second time on the first CPU architecture and the second CPU architecture; Function matching module, configured to perform cross-architecture function matching based on the multi-dimensional performance data on the first CPU architecture and the second CPU architecture to obtain a successfully matched function; Defect location module, configured to determine a first clock cycle number when the successfully matched function runs on the first CPU architecture and a second clock cycle number when the successfully matched function runs on the second CPU architecture; When the ratio of the first clock cycle number to the second clock cycle number is greater than a benchmark threshold, determine that the successfully matched function is the function that causes performance defects in the software to be detected.

[0013] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the method for discovering software performance defects based on cross-architecture comparison as described in any one of the above is implemented.

[0014] The present invention also provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method for discovering software performance defects based on cross-architecture comparison as described in any one of the above is implemented.

[0015] The present invention also provides a computer program product, including a computer program. When the computer program is executed by a processor, the method for discovering software performance defects based on cross-architecture comparison as described in any one of the above is implemented.

[0016] The method for discovering software performance defects based on cross-architecture comparison provided by the present invention automatically acquires multi-dimensional performance data by comparing the performance of the software to be detected on different CPU architectures in the same software. And an anomaly test case is determined according to the multi-dimensional performance data, and further a function with performance defects is determined. Thus, through cross-structure test verification, not only the accurate location of the performance bottleneck of the software to be detected is realized, but also the root cause of the performance difference is deeply explored and analyzed, providing data support and decision-making basis for subsequent software optimization. Description of the Drawings

[0017] To more clearly illustrate the technical solutions in the present invention or the prior art, the following will briefly introduce one by one the attached drawings required in the description of the embodiments or the prior art. Obviously, the attached drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other attached drawings can also be obtained based on these attached drawings.

[0018] Figure 1 It is a schematic flowchart of the software performance defect discovery method based on cross-architecture comparison provided by the present invention.

[0019] Figure 2 It is an application framework diagram of the software performance defect discovery method based on cross-architecture comparison provided by the present invention.

[0020] Figure 3 It is a schematic diagram of the selection of the anomaly detection algorithm provided by the present invention.

[0021] Figure 4 It is a schematic diagram of the principle of the function matching process provided by the present invention.

[0022] Figure 5 It is a schematic structural diagram of the software performance defect discovery device based on cross-architecture comparison provided by the present invention.

[0023] Figure 6 It is a schematic structural diagram of the electronic device provided by the present invention. Detailed implementation manners

[0024] To make the objectives, technical solutions, and advantages of the present invention clearer, the following will clearly and completely describe the technical solutions in the present invention in conjunction with the attached drawings in the present invention. Obviously, the described embodiments are some, rather than all, embodiments of the present invention. Based on the embodiments in the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention.

[0025] The software performance defect discovery method based on cross-architecture comparison provided by the present invention can be applied to the software testing scenario, and is specifically deployed in the server or terminal of the software testing system or platform, and is used to assist the software testing system or platform to test the software to be detected, so as to accurately discover software performance defects and feedback them to the software testing system or platform.

[0026] The following will describe the software performance defect discovery method based on cross-architecture comparison of the present invention in conjunction with the attached drawings. Figure 1 It is a schematic flowchart of the software performance defect discovery method based on cross-architecture comparison provided by the present invention. As Figure 1 shown, the method includes the following steps 101 to step 106.

[0027] Step 101: When the test sets of the software to be tested are first run on the first CPU architecture and the second CPU architecture respectively, collect the first performance data and the second performance data respectively.

[0028] To support anomaly detection and defect localization, it is necessary to collect the raw data related to the performance of the software to be tested during the testing process. Since cross-architecture implementation is required, in the embodiments of the present invention, a first CPU (Central Processing Unit) architecture and a second CPU architecture are designed, and there are differences in the performance and hardware parameters of these two CPU architectures. For the software to be tested, it is first deployed in the first CPU architecture and the second CPU architecture respectively, and then the test sets of the software to be tested are obtained. These test sets include test cases for testing the performance of the software to be tested. The test cases can be to make the software to be tested execute some application functions or run some algorithm programs, such as loop structure programs, etc. When the software to be tested runs on the first CPU architecture and the second CPU architecture respectively, the performance of the software to be tested is tested by executing these test sets.

[0029] Therefore, when the test sets of the software to be tested are first run on the first CPU architecture and the second CPU architecture respectively, collect the first performance data and the second performance data respectively. In order to efficiently capture data and ensure the accuracy and reliability of the data so that the subsequent analysis can reflect the real system state, in the embodiments of the present invention, the perf performance analysis tool is selected to collect the performance data during the running of the test sets of the software to be tested. The perf performance analysis tool can penetrate into all levels of the operating system and accurately capture various types of performance data. Its functions not only cover the monitoring of the overall system performance but also support data collection at the function level. Thus, it provides a more reliable basis for subsequent anomaly detection and defect localization. The perf performance analysis tool runs based on the hardware performance monitoring counter. By using the built-in performance monitoring hardware of the CPU, it can collect the counts of various hardware events such as cache hits, branch predictions, instruction executions, and cycle counts. Since it operates directly at the hardware level, this data collection method has extremely low performance overhead, can obtain the key performance indicators of the system in real time, and has almost no interference on the running of the monitored program, thus maximizing the preservation of the real performance of the system.

[0030] Here, when the test set of the software to be tested is first run on the first CPU architecture, collect the corresponding first performance data through the perf performance analysis tool. Similarly, when the test set of the software to be tested is first run on the second CPU architecture, collect the corresponding second performance data through the perf performance analysis tool. Generally speaking, the execution time is the key indicator for evaluating the performance of the software to be tested when executing the test cases. And according to the execution time of each test case, potential anomalies can be quickly identified. Therefore, the performance data collected by the perf performance analysis tool mainly includes the execution time of the test cases.

[0031] Step 102: Use the ratio of the first performance data and the second performance data as the performance data point to be detected, and call the autoencoder to perform anomaly detection on the performance data point to be detected, obtaining an anomaly test case.

[0032] To compare the performance differences of the software to be detected on different CPU architectures, in the embodiments of the present invention, after collecting the performance data on different CPU architectures, the ratio of the first performance data and the second performance data is used as the performance data point to be detected. For example, the ratio of the execution times of the corresponding test cases on the first CPU architecture and the second CPU architecture is used as the performance data point to be detected. This ratio can measure the performance differences of executing test cases in different CPU architectures.

[0033] Next, an anomaly detection algorithm is selected to perform anomaly detection on the performance data point to be detected, obtaining an anomaly test case. In some embodiments, as Figure 3 shown, there are various anomaly detection algorithms, which can be methods based on ensemble learning, methods based on generative adversarial networks, and methods based on autoencoders. These anomaly detection algorithms can all perform real-time parameter tuning, can perform anomaly detection on performance data, and obtain corresponding detection results. After comparing the silhouette coefficients for the detection results, the optimal algorithm can be selected as the anomaly detection algorithm.

[0034] In the embodiments of the present invention, anomaly detection needs to exclude the interference of hardware differences to find the data that deviates from the normal range. The autoencoder can capture and learn the complex patterns in the data and detect tiny anomalies in high-dimensional data. By compressing the data into a low-dimensional space and reconstructing it back to the original space, the autoencoder identifies the anomaly data points with large reconstruction errors. Since it performs excellently and stably on the test data set. Therefore, the embodiments of the present invention select the method based on the autoencoder as the anomaly detection algorithm, and perform anomaly detection on the performance data point to be detected by calling the autoencoder, obtaining an anomaly test case (testcase).

[0035] The autoencoder can accurately identify the anomaly data points of the performance data point to be detected, thereby determining the anomaly test case. Its identification effect depends on the anomaly detection algorithm, that is, the performance of the autoencoder itself. To optimize the effect of anomaly detection, the anomaly detection algorithm needs to be adaptively optimized. In the embodiments of the present invention, the particle swarm optimization algorithm is used to adaptively optimize the anomaly detection algorithm, that is, the autoencoder is adaptively optimized through the particle swarm optimization algorithm. The particle swarm optimization algorithm can automatically adjust the parameters of the autoencoder to ensure the best model performance. On this basis, more accurate and efficient anomaly detection can be achieved to ensure that the abnormal performance data can be reliably detected.

[0036] Step 103: When the abnormal test cases are secondarily run on the first CPU architecture and the second CPU architecture respectively, the corresponding multi-dimensional performance data are collected respectively.

[0037] After determining the abnormal test cases through Step 102, it is necessary to determine the performance defects existing in the software to be detected according to the abnormal test cases, that is, to perform defect localization. Here, the software to be detected is made to re-execute the abnormal test cases. Before execution, the compilation options are modified again for the abnormal test cases and the debugging environment is set up. When loading the debugging environment, it is necessary to load the test case symbol table, and the test case symbol table is a list of function names called during the execution of this test case by the software to be detected.

[0038] After loading the debugging environment, the software to be detected can be run on the first CPU architecture and the second CPU architecture respectively, and the abnormal test cases are executed. When the abnormal test cases are secondarily run on the first CPU architecture and the second CPU architecture respectively, the corresponding multi-dimensional performance data are collected respectively. The multi-dimensional performance data here are for the functions called when the software to be detected executes the abnormal test cases, that is, function-level multi-dimensional performance data. The collection method also uses the perf performance analysis tool. The function-level multi-dimensional performance data specifically include: the number of instructions, the number of cycles, the number of cache misses, the number of cache references, the number of branch predictions, the number of branch prediction misses, the number of L1 data cache loads, the number of L1 data cache load misses, the number of L1 data cache stores, the number of L1 data cache store misses, as well as the function execution time and the function call stack.

[0039] After collecting the multi-dimensional performance data, the target function with performance defects is determined based on the multi-dimensional performance data. Because it is necessary to load the test case symbol table when loading the debugging environment, by analyzing these multi-dimensional performance data, the performance status of the target function in the software to be detected when executing the abnormal test cases can be determined, and the key functions causing performance bottlenecks in the target function can be identified according to the test case symbol table.

[0040] Step 104: Perform cross-architecture function matching on the first CPU architecture and the second CPU architecture based on the multi-dimensional performance data to obtain successfully matched functions.

[0041] In order to further determine whether there are performance differences in functions and accurately identify the performance defect functions. In the embodiments of the present invention, after the multi-dimensional performance data are collected respectively, the localization of the performance defect functions is performed. Here, cross-architecture function matching is performed on the first CPU architecture and the second CPU architecture based on the multi-dimensional performance data to obtain successfully matched functions.

[0042] Specifically, first in the first CPU architecture, determine the functions that execute the exception test cases based on the collected multi-dimensional performance data. Then, based on these functions, determine the corresponding target functions from the multi-dimensional performance data of the first CPU architecture. Next, use the target functions as indices to match the corresponding functions to be matched from the multi-dimensional performance data corresponding to the second CPU architecture, thus achieving cross-architecture function matching. When the function matching is successful, this function to be matched is the successfully matched function.

[0043] During the matching process, it is necessary to ensure that the two functions participating in the matching (i.e., the function index corresponding to the first CPU architecture and the function to be matched corresponding to the second CPU architecture) are from the same object base class and command pattern. The matching principle is that the similarity of the function name strings of the two functions should reach a preset threshold.

[0044] Step 105: Determine the first clock cycle number when the successfully matched function runs in the first CPU architecture and the second clock cycle number when the successfully matched function runs in the second CPU architecture.

[0045] After the matching is completed and the successfully matched function is determined, the corresponding performance metrics can be tested in the first CPU architecture and the second CPU architecture respectively. Here, the number of clock cycles consumed by the successfully matched function on the CPU architecture is used as the performance metric. First, execute the successfully matched function in the first CPU architecture and the second CPU architecture respectively. During the execution process, determine the first clock cycle number when the successfully matched function runs in the first CPU architecture and the second clock cycle number when the successfully matched function runs in the second CPU architecture as the performance metric of the successfully matched function.

[0046] Step 106: When the ratio of the first clock cycle number to the second clock cycle number is greater than the benchmark threshold, determine that the successfully matched function is the function that causes performance defects in the software to be detected.

[0047] In addition, in order to eliminate the normal performance deviation caused by architecture differences, the embodiments of the present invention run some CPU benchmark programs on the two CPU architectures respectively and determine the corresponding performance standard values as the benchmark threshold. When the ratio of the first clock cycle number to the second clock cycle number is greater than the benchmark threshold, determine that the successfully matched function is the function that causes performance defects in the software to be detected.

[0048] If the ratio of the first clock cycle number to the second clock cycle number is greater than the benchmark threshold, it means that the successfully matched function is not a performance problem caused by architecture differences, but a performance bottleneck existing in the successfully matched function itself. From this, it can be determined that the successfully matched function is the function that causes performance defects in the software to be detected, realizing the positioning of the performance defect function and providing support and data basis for the subsequent maintenance work of the software to be detected, so as to perform optimization feedback on the software to be detected.

[0049] As Figure 2 shown Figure 2 is the application framework diagram of the software performance defect discovery method based on cross - architecture comparison provided by the present invention. The following combines Figure 2 to describe the application process of the software performance defect discovery method based on cross - architecture comparison provided by the present invention. As Figure 2 shown, the application process is generally divided into two stages. Among them, in stage 1, there are a data collection module 1 and an anomaly detection module, which mainly, based on the selected test set, quickly discover test cases (testcase) with performance defects through cross - architecture comparison. And in stage 2, there are a data collection module 2 and a defect location module, which mainly, based on the preliminarily screened abnormal test cases, locate the root cause from the full call chain functions and perf multi - dimensional performance data and optimize the feedback.

[0050] First, in data collection module 1, for the software ecosystem, that is, the software to be detected, which involves software such as cloud native, edge computing, artificial intelligence (AI), and big data. Select the test set as test cases according to the software package dependency library. Of course, for a certain type of software, the corresponding test set is selected, including the cloud native test set, the edge computing test set, the artificial intelligence (AI) test set, and the big data test set. Next, make the software ecosystem run the corresponding test sets in architecture A and architecture B respectively, and collect performance data such as the corresponding execution time and CPU time through the perf performance analysis tool. Here, architecture A and architecture B are two different CPU architectures, such as SOPHON SG2042 and Kunpeng 920 - 4826 respectively. The software environment in which the software ecosystem runs needs to be kept consistent, for example, the compiler is gcc12.3.1, the kernel is Linux6.6, the operating system is OpenEuler 24.03, and the C runtime library is glibc2.38, etc.

[0051] In the anomaly detection module, anomaly detection is performed according to the performance data collected in data collection module 1. The performance data includes the execution time of the corresponding testcase in architecture A test and the execution time of the corresponding testcase in architecture B test. The ratio of these two execution times is used as the data point to be detected for anomalies and input into the anomaly detection algorithm (such as an auto - encoder) to detect abnormal testcases. Thus, the process of stage 1 ends and enters the process of stage 2.

[0052] In Phase 2, first, the data acquisition module 2 loads the debugging environment according to the abnormal test cases screened in Phase 1, loads the symbol table information, and configures the perf multi-dimensional performance sampling. Then, the abnormal test cases are executed on Architecture A and Architecture B respectively to collect multi-dimensional performance data, specifically including the function-level multi-dimensional performance data corresponding to the Anomaly test in Architecture A and the function-level multi-dimensional performance data corresponding to the Anomaly test in Architecture B. In the defect location module, defect location is performed based on the multi-dimensional performance data collected by the data acquisition module 2. The multi-dimensional performance data includes: time, number of instructions, number of cycles, cache, etc. In addition, it also involves the performance analysis of the full call chain functions of the test cases, including applications, frameworks, basic libraries, kernels, etc. Through the multi-dimensional performance data, the functions with performance defects can be determined, and function matching is performed in Architecture A and Architecture B to determine the successfully matched functions. Then, the number of clock cycles of the successfully matched functions in Architecture A and Architecture B is tested, and combined with the CPU benchmark difference, the problem functions are determined, that is, the functions with performance defects in the software ecosystem. For the problem functions, the performance anomaly description and the function location can be informed to the testers. Through the manual assisted analysis and optimization by the testers, and then the optimization feedback is sent back to the software ecosystem, thus the process of Phase 2 ends and the entire application process is introduced.

[0053] In the embodiment of the present invention, by comparing the performance of the software to be detected on different CPU architectures in the same software, multi-dimensional performance data is automatically collected. And based on the multi-dimensional performance data, abnormal test cases are determined, and further the target functions with performance defects are determined. Thus, through cross-structure test verification, not only the accurate location of the performance bottleneck of the software to be detected is realized, but also the root causes of the performance differences are deeply explored and analyzed, providing data support and decision-making basis for subsequent software optimization. In addition, the embodiment of the present invention does not require aligning the compilation options in the software system, simplifies the operation process, reduces the technical implementation threshold, and improves the applicability.

[0054] In some embodiments, the process of locating performance defects mainly focuses on function-level matching, that is, cross-architecture function matching is performed based on the target functions on the first CPU architecture and the second CPU architecture to obtain successfully matched functions.

[0055] Specifically, the target functions in the multi-dimensional performance data corresponding to the first CPU architecture are used as function indexes. These target functions are the functions that need to be called when the software to be detected executes abnormal test cases, and can be determined one by one through the multi-dimensional performance data. Then, each function to be matched is traversed from the multi-dimensional performance data corresponding to the second CPU architecture according to the function index. According to the multi-dimensional performance data corresponding to the second CPU architecture, the functions that need to be called when the software to be detected executes abnormal test cases can also be determined as the functions to be matched.

[0056] After traversing to a function to be matched, it is matched with the function index. Here, when performing the matching during the traversal process, when the function index and the function to be matched meet the following conditions, the function to be matched is determined to be a successfully matched function.

[0057] The first condition that needs to be met is that the function to be matched and the function index come from the same base class (the object base class) and command pattern (the Command command pattern). This is to ensure that the call stacks of the two functions are the same, serving as a prerequisite for a successful match.

[0058] Next, the second condition that needs to be met is that the similarity between the function name of the function index and the function name of the function to be matched reaches a preset threshold. That is, the similarity of the strings represented by the Symbols of the two functions needs to reach the preset threshold. Of course, the similarity is calculated for the strings. The similarity can be calculated as the Jaccard distance, cosine similarity, or mapped to binary strings, multi-dimensional vectors, etc. and then calculate the similarity.

[0059] The preset threshold is the similarity threshold, for example, set to 95%, which is used to measure the matching degree of functions. The similarity threshold can be dynamically adjusted according to the actual situation to ensure the matching accuracy.

[0060] When the function index corresponding to the first CPU architecture and the function to be matched corresponding to the second CPU architecture meet the above two conditions, it can be said that the two functions are successfully matched.

[0061] In some embodiments, there are multiple target functions in the multi-dimensional performance data collected by the first CPU architecture. Then, there are also multiple functions to be matched corresponding to the second CPU architecture. Therefore, this is a many-to-many matching process, and this process can be referred to Figure 4As shown. At the beginning, traverse all functions of architecture A, first point to the first function of architecture A, that is, take the first target function in the multi-dimensional performance data corresponding to the first CPU architecture as the function index. Then determine whether all functions of architecture A have been traversed. If not, starting from the first function of architecture A, traverse all functions of architecture B, first point to the first function of architecture B, that is, the first function to be matched in the multi-dimensional performance data corresponding to the second CPU architecture. Next, determine whether all functions of architecture B have been traversed. If not, match according to the first function of architecture A and the first function of architecture B to determine whether the functions belong to the same Object (base class) and Command (command pattern). If so, further determine whether the similarity of the function symbol reaches the preset threshold. If so, it means the match is successful, store the match information, and continue to determine whether all functions of architecture B have been traversed to point to the next function of architecture B, that is, the second function to be matched in the multi-dimensional performance data corresponding to the second CPU architecture.

[0062] When continuing to determine whether all functions of architecture B have been traversed, if so, it means that the matching of the first function of architecture A is completed, then continue to point to the next function of architecture A, that is, the second target function in the multi-dimensional performance data corresponding to the first CPU architecture, and continue to use it as the function index to match each function in architecture B one by one. In this way, until all functions of architecture A have been traversed, the matching process ends.

[0063] In an embodiment of the present invention, it is proposed to match two functions across architectures by means of function name string matching, which simplifies the process of cross-architecture matching. Even in the case of a large amount of data and a large number of functions, it is possible to quickly locate the performance problems of functions without omission, thereby improving the efficiency of function performance mining.

[0064] In some embodiments, when performing cross-architecture function matching between the first CPU architecture and the second CPU architecture, it is necessary to calculate the similarity between the function name of the function index and the function name of the function to be matched. The following introduces the calculation process of the similarity between the function name of the function index and the function name of the function to be matched.

[0065] First, obtain the first function name string of the function index and the second function name string of the function to be matched.

[0066] Here, directly extract the function name of the function index and the function name of the function to be matched. The function name generally consists of at least one word or a string of English characters. Here, directly extract the function name strings of both to calculate the similarity.

[0067] During the process of calculating the similarity, the first function name string and the second function name string are vectorized to obtain the corresponding first string vector and second string vector. By vectorizing, the string is mapped to the vector dimension. The method of vectorization can be to use a text encoder for character encoding to obtain the corresponding encoded vector.

[0068] Next, determine the vector similarity between the first string vector and the second string vector. The method of calculating the vector similarity can be edit distance, Euclidean distance, cosine similarity, etc. Finally, use the vector similarity as the similarity between the function name of the function index and the function name of the function to be matched, and then determine whether the similarity is greater than the preset threshold to determine whether the function index and the function to be matched are successfully matched.

[0069] In the embodiment of the present invention, by calculating the similarity of the function name string to measure the matching degree of two functions, the similarity calculated by string vectorization can ensure the accuracy of similarity calculation even in the case of a large amount of data and a large number of functions. And by calculating the similarity through string vectorization to determine whether to match also simplifies the matching process.

[0070] In order to eliminate the normal performance deviation caused by architecture differences, it is necessary to call some CPU benchmark programs to run on two CPU architectures respectively, and determine the corresponding performance standard value as the benchmark threshold. Then judge whether the ratio of the first clock cycle number to the second clock cycle number is greater than the benchmark threshold to determine whether the successfully matched function is the function that causes the performance defect of the software to be detected.

[0071] This CPU benchmark program is used to judge whether the performance difference between functions is within the normal range. In some embodiments, the benchmark threshold is determined according to the SPEC CPU benchmark test program, and SPEC CPU is the CPU benchmark test program of the Standard Performance Evaluation Corporation. It is used to evaluate the computing power differences of different architectures, has high operating system independence, and hardly depends on the kernel interface, thus effectively avoiding the influence of the kernel on performance differences. Through the SPEC CPU test, the computing power between different architectures can be compared, and the performance differences brought by the hardware platform can be accurately reflected. The process of determining the benchmark threshold through the SPEC CPU benchmark test program is introduced below.

[0072] First, in the first CPU architecture and the second CPU architecture, the SPEC CPU benchmark program is executed respectively, and the corresponding first performance test result and second performance test result are collected during the execution. Then, the ratio of the first performance test result to the second performance test result is used as the benchmark threshold. The first performance test result and the second performance test result here are similar to the above-mentioned multi-dimensional performance data, and will not be elaborated here.

[0073] In the embodiment of the present invention, the benchmark threshold is determined through the SPEC CPU benchmark program, which is used to judge whether there is a performance anomaly in the successfully matched function, ensure that the performance difference between functions is within the normal range, can eliminate the normal performance deviation caused by architecture differences, and more accurately identify and locate actual performance anomalies.

[0074] In some embodiments, when the abnormal test cases are second-run on the first CPU architecture and the second CPU architecture respectively, after the corresponding multi-dimensional performance data is collected respectively, cross-architecture function matching is performed on the target function in the first CPU architecture and the second CPU architecture to obtain the functions that fail to be successfully matched. This function that fails to be successfully matched is a target function with the multi-dimensional performance data corresponding to the first CPU architecture as the function index and that fails to match the function to be matched in the multi-dimensional performance data corresponding to the second CPU architecture.

[0075] When performing cross-architecture function matching on the first CPU architecture and the second CPU architecture based on the multi-dimensional performance data, two different function matching results will be generated. When the matching is successful, that is, when the function index and the function to be matched meet the above two conditions, the function to be matched is used as the successfully matched function.

[0076] And there will also be a situation where the matching fails here, that is, the function index and the function to be matched do not meet the above two conditions. For example, the similarity between the function name of the function index and the function name of the function to be matched is less than or equal to the similarity threshold. Therefore, there will also be a situation where a certain target function is used as the function index in the multi-dimensional performance data collected in the first CPU architecture, but fails to be successfully matched with the function to be matched in the second CPU architecture. At this time, this target function is used as the function that fails to be successfully matched.

[0077] These functions that fail to be successfully matched cannot be directly compared in terms of performance across architectures due to architecture optimization or function characteristic differences. However, the resource occupancy data of the functions that fail to be successfully matched in the first CPU architecture can also be determined here. The resource occupancy data includes the proportion of CPU resource occupancy and the execution time of executing the functions that fail to be successfully matched. Whether it is a potential abnormal data point can also be judged through the resource occupancy data.

[0078] The judgment criterion can be to preset a threshold according to the actual situation. When the resource occupancy data reaches the set threshold, it is determined that the function that fails to be successfully matched is the function that causes performance defects in the software to be detected. For example, when the proportion of CPU resource occupancy reaches the preset proportion threshold, or the execution time exceeds the preset time threshold, it indicates that the function that fails to be successfully matched is the function that causes performance defects in the software to be detected.

[0079] Of course, in actual implementation, this judgment criterion may not be effective. If there is an offset, further determination is required, such as through manual auxiliary analysis. Use other test environments and performance testing methods to further test this function that fails to be successfully matched.

[0080] In the embodiment of the present invention, when the function in the multi-dimensional performance data fails to achieve cross-architecture matching, the resource occupancy data running on a single architecture is used to further judge the function that fails to be successfully matched, and combined with manual auxiliary analysis, thereby eliminating the influence on performance anomalies caused by architecture optimization or function characteristic differences when cross-architecture matching fails.

[0081] In some embodiments, after determining the function that causes performance defects in the software to be detected through cross-architecture matching, performance optimization can also be performed on the function that causes performance defects in the software to be detected to obtain an optimized function. Here, performance optimization can be rewriting the function calculation logic therein, optimizing the code length, optimizing the loop iteration structure, etc. For the optimized function in the software to be detected, cross-architecture comparison and matching can be continued, that is, continue to execute the above steps 101 to 103 using the test set of the software to be detected.

[0082] When the optimized function runs on the first CPU architecture and the second CPU architecture respectively, the corresponding running performance data is collected. The collection method can be to use the perf performance analysis tool. The running performance data can be the multi-dimensional performance data mentioned above, which will not be elaborated here.

[0083] Next, determine the performance optimization result of the optimized function according to the running performance data. In this process, cross-architecture function matching is performed on the first CPU architecture and the second CPU architecture based on the running performance data to obtain a successfully matched function, and then determine the number of clock cycles when the successfully matched function runs on the first CPU architecture and the number of clock cycles when the successfully matched function runs on the second CPU architecture, and determine the ratio of the two clock cycles as the performance optimization result of the optimized function. Among them, the process of cross-architecture function matching can refer to the above step 104, and the process of determining the number of clock cycles can refer to the above step 105, which will not be elaborated here.

[0084] Next, it is determined whether the performance optimization result of the optimized function is greater than the benchmark threshold determined by the SPEC CPU benchmark program. When it is less than the benchmark threshold, it indicates that the performance optimization result characterizes that the optimized function is not the function that causes performance defects in the software to be detected. When it is greater than the benchmark threshold, it indicates that the performance optimization result characterizes that the optimized function is still the function that causes performance defects in the software to be detected.

[0085] When the performance optimization result characterizes that the optimized function is not the function that causes performance defects in the software to be detected, update the function with performance defects in the software to be detected according to the optimized function. Here, when the optimized function is not the function that causes performance defects in the software to be detected, it indicates that the effectiveness of the performance optimization has been verified. Therefore, update the function with performance defects in the software to be detected through the optimized function, so as to overcome the performance defects existing in the software to be detected.

[0086] When the performance optimization result characterizes that the optimized function is the function that causes performance defects in the software to be detected, it indicates that the performance optimization situation is poor, and the optimized function still causes performance defects in the software to be detected. Then, performance optimization can be continued, such as rewriting the function calculation logic, optimizing the code length, optimizing the loop iteration structure, etc., and continue to collect the corresponding running performance data for testing until the performance optimization result characterizes that the optimized function is not the function that causes performance defects in the software to be detected.

[0087] In the embodiment of the present invention, after discovering the function that causes performance defects in the software to be detected, perform performance optimization on this function, and then continue to test the performance optimization result of the optimized function to ensure the effectiveness of the performance optimization, and update the function that causes performance defects in the software to be detected through the optimized function. When it is determined that the performance optimization situation is poor through the performance optimization result, continue to perform iterative optimization, thereby realizing a closed-loop optimization mechanism in the software to be detected, which can automatically perform performance detection and performance tuning on the software to be detected, so as to promote its performance improvement and wide application in the software ecosystem.

[0088] Next, a software performance defect discovery device based on cross-architecture comparison provided by the present invention will be described. The software performance defect discovery device based on cross-architecture comparison described below can be mutually corresponding and referred to the software performance defect discovery method based on cross-architecture comparison described above.

[0089] See Figure 5 , Figure 5 is a schematic structural diagram of a software performance defect discovery device based on cross-architecture comparison provided by the present invention. As Figure 5As shown in the figure, the software performance defect discovery device based on cross-architecture comparison includes: a data collection module 501, an anomaly detection module 502, a function matching module 503, and a defect location module 504. Specifically, the data collection module 501 is configured to collect first performance data and second performance data respectively when the test set of the software to be tested is first run on the first CPU architecture and the second CPU architecture; the anomaly detection module 502 is configured to use the ratio of the first performance data and the second performance data as the performance data point to be detected, and call an autoencoder to perform anomaly detection on the performance data point to be detected to obtain an anomaly test case, where the autoencoder is adaptively optimized by a particle swarm optimization algorithm; the data collection module 501 is further configured to collect corresponding multi-dimensional performance data respectively when the anomaly test case is second run on the first CPU architecture and the second CPU architecture, and determine a target function with performance defects based on the multi-dimensional performance data; the function matching module 503 is configured to perform cross-architecture function matching based on the target function on the first CPU architecture and the second CPU architecture to obtain a successfully matched function; the defect location module 504 is configured to determine the first clock cycle number when the successfully matched function runs on the first CPU architecture and the second clock cycle number when the successfully matched function runs on the second CPU architecture; when the ratio of the first clock cycle number to the second clock cycle number is greater than a benchmark threshold, determine that the successfully matched function is the function that causes the software to be tested to have performance defects.

[0090] It should be noted that the beneficial effects of the software performance defect discovery device based on cross-architecture comparison here can correspond to those of the software performance defect discovery method based on cross-architecture comparison in the above text. Therefore, the beneficial effects of the software performance defect discovery device based on cross-architecture comparison are not elaborated here.

[0091] Figure 6 An example of the entity structure diagram of an electronic device is shown in Figure 6As shown in the figure, the electronic device may include: a processor 610, a communications interface 620, a memory 630, and a communication bus 640. Among them, the processor 610, the communications interface 620, and the memory 630 complete communication with each other through the communication bus 640. The processor 610 may call the logical instructions in the memory 630 to execute a software performance defect discovery method based on cross-architecture comparison. The method includes: when the test set of the software to be detected is first run on the first CPU architecture and the second CPU architecture respectively, collecting first performance data and second performance data respectively; using the ratio of the first performance data and the second performance data as the performance data point to be detected, and calling an autoencoder to perform anomaly detection on the performance data point to be detected to obtain an abnormal test case, where the autoencoder is adaptively optimized through a particle swarm optimization algorithm; when the abnormal test case is second-run on the first CPU architecture and the second CPU architecture respectively, collecting corresponding multi-dimensional performance data respectively; performing cross-architecture function matching based on the multi-dimensional performance data on the first CPU architecture and the second CPU architecture to obtain a successfully matched function; determining the first clock cycle number when the successfully matched function runs on the first CPU architecture and the second clock cycle number when the successfully matched function runs on the second CPU architecture; when the ratio of the first clock cycle number to the second clock cycle number is greater than a benchmark threshold, determining that the successfully matched function is the function that causes the performance defect of the software to be detected.

[0092] In addition, when the logical instructions in the above-mentioned memory 630 are implemented in the form of software functional units and sold or used as an independent product, they may be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of this technical solution, may be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROMs, Read-Only Memories), random access memories (RAMs, Random Access Memories), magnetic disks, or optical discs that can store program codes.

[0093] On the other hand, the present invention also provides a computer program product, which includes a computer program. The computer program can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the software performance defect discovery method based on cross-architecture comparison provided by the above-mentioned various methods. The method includes: when the test set of the software to be detected is first run on the first CPU architecture and the second CPU architecture respectively, collecting first performance data and second performance data; taking the ratio of the first performance data and the second performance data as the performance data point to be detected, and calling an autoencoder to perform anomaly detection on the performance data point to be detected, obtaining an abnormal test case, wherein the autoencoder is adaptively optimized by a particle swarm optimization algorithm; when the abnormal test case is second-run on the first CPU architecture and the second CPU architecture respectively, collecting corresponding multi-dimensional performance data; performing cross-architecture function matching based on the multi-dimensional performance data on the first CPU architecture and the second CPU architecture, obtaining a successfully matched function; determining the first clock cycle number when the successfully matched function runs on the first CPU architecture and the second clock cycle number when the successfully matched function runs on the second CPU architecture; when the ratio of the first clock cycle number to the second clock cycle number is greater than a benchmark threshold, determining that the successfully matched function is the function causing the performance defect of the software to be detected.

[0094] On another aspect, the present invention also provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it is implemented to execute the software performance defect discovery method based on cross-architecture comparison provided by the above-mentioned various methods. The method includes: when the test set of the software to be detected is first run on the first CPU architecture and the second CPU architecture respectively, collecting first performance data and second performance data; taking the ratio of the first performance data and the second performance data as the performance data point to be detected, and calling an autoencoder to perform anomaly detection on the performance data point to be detected, obtaining an abnormal test case, wherein the autoencoder is adaptively optimized by a particle swarm optimization algorithm; when the abnormal test case is second-run on the first CPU architecture and the second CPU architecture respectively, collecting corresponding multi-dimensional performance data; performing cross-architecture function matching based on the multi-dimensional performance data on the first CPU architecture and the second CPU architecture, obtaining a successfully matched function; determining the first clock cycle number when the successfully matched function runs on the first CPU architecture and the second clock cycle number when the successfully matched function runs on the second CPU architecture; when the ratio of the first clock cycle number to the second clock cycle number is greater than a benchmark threshold, determining that the successfully matched function is the function causing the performance defect of the software to be detected.

[0095] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. A person of ordinary skill in the art can understand and implement it without creative effort.

[0096] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on such an understanding, the essence of the above technical solution, 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 for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0097] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments or perform equivalent replacements for some of the technical features. These modifications or replacements 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 the present invention.

Claims

1. A software performance defect discovery method based on cross-architecture comparison, characterized in that The method includes: When the test set of the software to be detected is first run on the first CPU architecture and the second CPU architecture respectively, the first performance data and the second performance data are collected respectively; Taking the ratio of the first performance data and the second performance data as the performance data point to be detected, and calling an autoencoder to perform anomaly detection on the performance data point to be detected to obtain an anomaly test case, where the autoencoder is adaptively optimized by a particle swarm optimization algorithm; When the anomaly test case is second-run on the first CPU architecture and the second CPU architecture respectively, the corresponding multi-dimensional performance data is collected respectively; Performing cross-architecture function matching based on the multi-dimensional performance data on the first CPU architecture and the second CPU architecture to obtain a successfully matched function; Determining the first clock cycle number when the successfully matched function runs on the first CPU architecture and the second clock cycle number when the successfully matched function runs on the second CPU architecture; When the ratio of the first clock cycle number to the second clock cycle number is greater than the benchmark threshold, determining that the successfully matched function is the function that causes the performance defect of the software to be detected.

2. The software performance defect discovery method based on cross-architecture comparison according to claim 1, wherein The performing cross-architecture function matching based on the multi-dimensional performance data on the first CPU architecture and the second CPU architecture to obtain a successfully matched function includes: Taking the target function in the multi-dimensional performance data collected on the first CPU architecture as the function index; Traversing each function to be matched in the multi-dimensional performance data collected on the second CPU architecture according to the function index; During the traversal, when the function index and the function to be matched meet the following conditions, determining that the function to be matched is a successfully matched function: The function to be matched and the function index come from the same base class and command pattern; The similarity between the function name of the function index and the function name of the function to be matched reaches a preset threshold.

3. The software performance defect discovery method based on cross-architecture comparison according to claim 2, wherein The calculation process of the similarity between the function name of the function index and the function name of the function to be matched includes: Obtaining the first function name string of the function index and the second function name string of the function to be matched; Vectorizing the first function name string and the second function name string to obtain corresponding first string vector and second string vector; Determining the vector similarity between the first string vector and the second string vector, and taking the vector similarity as the similarity between the function name of the function index and the function name of the function to be matched.

4. The software performance defect discovery method based on cross-architecture comparison according to claim 1, wherein The benchmark threshold is determined according to the SPEC CPU benchmark program, and the determination process of the benchmark threshold includes: Executing the SPEC CPU benchmark program on the first CPU architecture and the second CPU architecture respectively, and collecting the corresponding first performance test result and second performance test result during the execution; Taking the ratio of the first performance test result to the second performance test result as the benchmark threshold.

5. The software performance defect discovery method based on cross-architecture comparison according to claim 1, wherein After the corresponding multi-dimensional performance data is collected respectively, the method further includes: Performing cross-architecture function matching between the first CPU architecture and the second CPU architecture based on the multi-dimensional performance data to obtain functions that fail to be matched. The functions that fail to be matched are target functions for which the multi-dimensional performance data collected in the first CPU architecture is used as a function index and the target function to be matched cannot be found in the multi-dimensional performance data collected in the second CPU architecture; Determining the resource occupancy data of the functions that fail to be matched in the first CPU architecture, and when the resource occupancy data reaches a set threshold, determining the functions that fail to be matched as functions causing performance defects in the software to be detected.

6. The method for discovering software performance defects based on cross-architecture comparison according to claim 1, wherein The method further includes: Performing performance optimization on the functions causing performance defects in the software to be detected to obtain optimized functions; When the optimized functions are running in the first CPU architecture and the second CPU architecture respectively, collecting the corresponding running performance data; Determining the performance optimization result of the optimized functions according to the running performance data; When the performance optimization result indicates that the optimized functions are not functions causing performance defects in the software to be detected, updating the functions with performance defects in the software to be detected according to the optimized functions.

7. A software performance defect discovery device based on cross-architecture comparison, characterized in that The apparatus includes: A data acquisition module, configured to respectively acquire first performance data and second performance data when the test set of the software to be detected is running for the first time in the first CPU architecture and the second CPU architecture respectively; An anomaly detection module, configured to use the ratio of the first performance data and the second performance data as a performance data point to be detected, and call an autoencoder to perform anomaly detection on the performance data point to be detected to obtain an anomaly test case, where the autoencoder is adaptively optimized by a particle swarm optimization algorithm; The data acquisition module is further configured to respectively acquire corresponding multi-dimensional performance data when the anomaly test case is running for the second time in the first CPU architecture and the second CPU architecture respectively; A function matching module, configured to perform cross-architecture function matching between the first CPU architecture and the second CPU architecture based on the multi-dimensional performance data to obtain functions that are successfully matched; A defect location module, configured to determine the number of first clock cycles when the successfully matched functions are running in the first CPU architecture and the number of second clock cycles when the successfully matched functions are running in the second CPU architecture; When the ratio of the number of first clock cycles to the number of second clock cycles is greater than a reference threshold, determining the successfully matched functions as functions causing performance defects in the software to be detected.

8. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the method for discovering software performance defects based on cross-architecture comparison according to any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method for discovering software performance defects based on cross-architecture comparison according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method for discovering software performance defects based on cross-architecture comparison according to any one of claims 1 to 6.

Images