Program performance analysis system, program performance analysis method, and computer program product

Abstract

The invention discloses a program performance analysis system and a program performance analysis method, which can automatically associate code logic with performance data during program running. The analysis system comprises a large model layer, an intelligent agent layer and a tool box layer. The planner is configured to decompose a program performance analysis request into a plurality of performance analysis tasks; and for each performance analysis task, generating a static code analysis instruction. The actuator is configured to analyze the source code based on the static code analysis instruction to generate a static analysis result; and determining performance data to be acquired and a data acquisition tool to be called based on the static analysis result, and generating a data acquisition instruction. The data acquisition processor is configured to call the data acquisition tool according to the data acquisition instruction to acquire performance data and generate a dynamic analysis result; and associating the dynamic analysis result with the static analysis result to generate an associated analysis result.

Description

Technical Field

[0001] The present application relates to the field of software engineering, and more specifically, to a program performance analysis system, a program performance analysis method, and a computer program product. Background Art

[0002] With the rapid development of information technology, the scale and complexity of software applications are growing exponentially. Modern software systems, especially large-scale enterprise applications, data processing platforms, real-time interactive systems, cloud computing services, electronic gaming services, and embedded systems, have increasingly stringent performance requirements.

[0003] The performance of a program is usually reflected in key indicators such as execution time (response latency), throughput (processing volume per unit time), resource utilization (CPU, memory, disk I / O, network bandwidth, etc.), and scalability. These indicators directly determine user experience, system carrying capacity, operating costs, and the achievement of business goals.

[0004] Currently, traditional analysis tools such as pprof and VTune are mainly used for program performance analysis. However, these traditional analysis tools all have a common problem, that is, although they can collect performance data and aggregate these performance data, they cannot provide correlation analysis between code logic and performance data. Such correlation analysis needs to rely entirely on manual experience. Specifically, developers need to manually compare flame graphs with code snippets to locate bottlenecks, which is time-consuming. Even for an experienced developer or tester, it usually takes several days to effectively complete the interpretation. More specifically, the flame graph usually only displays the function name, and does not directly display the source code file path and specific line number of the code that caused the function to consume resources.

[0005] For example, after seeing the hot function names marked on the flame graph, the developer must first perform the following operations:

[0006] Open the project's source code repository;

[0007] Search the code base for the name of the hotspot function;

[0008] Locate the file and specific line number where the hotspot function is located;

[0009] Carefully read and analyze the logic of the hotspot function and its context (calling the hotspot function).

[0010] However, simply finding the hot function in the source code is not enough. The flame graph also displays the function call stack (called the call stack for short). Developers need to combine the call stack information in the flame graph with the source code to understand the following:

[0011] Why is this hot function called frequently?

[0012] Which part of the logic within the hot function causes high resource consumption?

[0013] Is the high resource consumption reasonable? Is there room for optimization?

[0014] In other words, traditional performance analysis tools cannot automatically associate code logic with performance data.

[0015] Furthermore, the closed-loop architecture of traditional performance analysis tools also limits data source scalability. Specifically, traditional performance analysis tools use a static, bundled data access method, employing closed protocols (supporting only pre-set data formats), relying on built-in collection agents, and failing to integrate new hardware or custom metrics (e.g., GPU temperature, service queue depth, etc.). Consequently, when analyzing non-standard data sources, developers must manually convert code formats or rewrite it, which is costly.

[0016] To overcome the technical limitations of traditional analysis tools, which rely on manual experience, automated solutions are being sought. Currently, large language models (LLMs) possess powerful semantic understanding capabilities, and general-purpose intelligent agent frameworks based on LLMs, such as AutoGen, are widely used in various fields.

[0017] However, for the application of program performance analysis, since the general agent framework does not have built-in performance analysis domain knowledge, the general agent framework is still unable to correctly associate code logic with sampling data (i.e., collected performance data) and cannot achieve joint modeling of the two (for example, automatic correlation analysis of CPU hotspots and loop bodies).

[0018] In addition, although the general intelligent agent framework can process multimodal performance data to a certain extent, due to the lack of built-in performance analysis domain knowledge, there is still a technical defect that makes it difficult to align multimodal data, resulting in modal fragmentation (for example, it is difficult to align log text with the time series of performance data).

[0019] Furthermore, general-purpose agent architectures often hard-code data sources, rendering them "hard-coded" in the code. Furthermore, general-purpose agent architectures require the acquisition of specialized data and even pre-processing. Adding a new data source necessitates code rewriting. This means that even when using a general-purpose agent architecture for program performance analysis, the technical issue of data source rigidity persists. Summary of the Invention

[0020] Technical problem to be solved by the invention

[0021] This application is formed to solve the above technical problems, and its purpose is to provide a program performance analysis system that can automatically associate code logic with performance data during program runtime. On this basis, this application also provides a program performance analysis method and a computer program product.

[0022] Technical solutions used to solve technical problems

[0023] A technical solution of the present application provides a program performance analysis system for analyzing the performance of a target program, including:

[0024] An agent layer, comprising a planner, an executor, and a data acquisition processor;

[0025] A large model layer, comprising large model instances for invocation by the agent layer; and

[0026] The toolbox layer includes code analysis tools and data collection tools for the agent layer to call,

[0027] The planner is configured to, upon receiving a program performance analysis request for the target program, call the big model instance in the big model layer to perform the following actions:

[0028] Decomposing the program performance analysis request into a plurality of performance analysis tasks; and

[0029] For each performance analysis task, generate static code analysis instructions,

[0030] The actuator is configured to:

[0031] Based on the received static code analysis instruction, calling a code analysis tool from the toolbox layer to analyze the source code of the target program to generate a static analysis result, wherein the static analysis result includes code anchor metadata of the source code of the target program; and

[0032] Determine the performance data to be collected and the data collection tool to be called based on the static analysis results, and generate a data collection instruction, wherein the data collection instruction includes relevant information of the performance data to be collected and the data collection tool to be called,

[0033] The data acquisition processor is configured to:

[0034] calling the data collection tool from the toolbox layer according to the data collection instruction to collect the performance data, so as to generate a dynamic analysis result including the performance data; and

[0035] The dynamic analysis result is associated with the static analysis result based on the code anchor metadata to generate an associated analysis result.

[0036] Optionally, the program performance analysis system further includes a report generating unit, configured to generate a program performance analysis report based at least on the correlation analysis result.

[0037] Another technical solution of the present application provides a program performance analysis method, which analyzes the performance of a target program based on a large model-driven intelligent agent architecture. The large model-driven intelligent agent architecture includes:

[0038] An agent layer, comprising a planner, an executor, and a data acquisition processor;

[0039] A large model layer, comprising large model instances for invocation by the agent layer; and

[0040] A toolbox layer, which includes code analysis tools and data collection tools for the agent layer to call,

[0041] The program performance analysis method comprises the following steps:

[0042] Decomposing the program performance analysis request received by the planner into a plurality of performance analysis tasks;

[0043] causing the planner to generate static code analysis instructions for each performance analysis task;

[0044] causing the executor to call a code analysis tool from the toolbox layer to analyze the source code of the target program based on the static code analysis instruction to generate a static analysis result, wherein the static analysis result includes code anchor metadata of the source code of the target program;

[0045] The executor determines, based on the static analysis result, performance data to be collected and a data collection tool to be called, and generates a data collection instruction, wherein the data collection instruction includes relevant information of the performance data to be collected and the data collection tool to be called;

[0046] causing the data acquisition processor to call the data acquisition tool from the toolbox layer according to the data acquisition instruction to collect the performance data, so as to generate a dynamic analysis result including the performance data; and

[0047] The data acquisition processor is enabled to associate the dynamic analysis result with the static analysis result based on the code anchor metadata to generate an associated analysis result.

[0048] Effects of the Invention

[0049] The program performance analysis system and method described in this application can automatically associate code logic with program runtime performance data. Specifically, leveraging the natural language understanding and processing capabilities of a large language model, program performance analysis requests presented in natural language can be automatically split into multiple performance analysis tasks. Furthermore, through the collaborative work between the various modules of the intelligent agent and the automatic interaction between the intelligent agent and various tools (e.g., various static and dynamic code analysis tools), the execution of each performance analysis task can be automatically completed, and an associated analysis result can be generated that associates static analysis results with dynamic analysis results. This allows code logic to be associated with program runtime performance data without the need for manual intervention or human experience, thereby automatically locating the specific location of code bottlenecks and improving the efficiency of program performance analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 2 is a schematic diagram showing the system architecture of a program performance analysis system according to one embodiment of the present application.

[0051] Figure 2 This is a timing diagram showing a program performance analysis method according to one embodiment of the present application.

[0052] Figure 3 Is based on Figure 2 The flowchart of the main steps of the program performance analysis method for performing performance analysis of test cases is shown.

[0053] Figure 4 This is a timing diagram showing a first variation of the program performance analysis method according to one embodiment of the present application.

[0054] Figure 5 This is a flowchart showing the main steps in the fifth variation of the program performance analysis method according to one embodiment of the present application. DETAILED DESCRIPTION

[0055] [Architecture of the program performance analysis system]

[0056] Figure 1 A schematic diagram of the system architecture of a program performance analysis system S according to an embodiment of the present application is shown.

[0057] like Figure 1 As shown, the program performance analysis system S of this embodiment includes a large model layer S1, an agent layer S2, a toolbox layer S3, a report generation unit S4, and a knowledge management unit S5. It should be noted that the report generation unit S4 and the knowledge management unit S5 are optional for the program performance analysis system S. In other words, the program performance analysis system S does not necessarily need to include the report generation unit S4 and the knowledge management unit S5.

[0058] [Large model layer S1]

[0059] The large model layer, also known as the large language model layer, provides different types of large language model instances. These include general reasoning models (e.g., ChatGPT, Deepseek), code expert models (e.g., CodeLLaMA, WizardCoder), domain knowledge models (e.g., BloombergGPT, Domain-LLM), and multimodal alignment models (e.g., Flamingo, Kosmos). These different large model instances can be selected and interacted with by the various modules in the agent layer S2 (e.g., planner S21, executor S22, data acquisition processor S23), to handle specific tasks.

[0060] [Intelligent Body Layer S2]

[0061] Before describing the specific structure of the agent layer S2, the concept of "agent" is explained.

[0062] An agent is a system with autonomy, perception, and execution capabilities, capable of interacting with the outside world and completing specific tasks in complex and changing environments. An agent is characterized by its independent decision-making ability, capable of making logical judgments and taking actions based on collected information without human intervention.

[0063] This application uses an agent technology framework driven by a large model. Specifically, the interaction between the agent layer and the large model layer is as follows:

[0064] The agent layer (or rather, the modules within the agent layer) sends queries and context to the big model layer and updates its memory; and

[0065] The big model layer parses the query and context sent from the agent layer and returns the parsed results to the agent layer.

[0066] like Figure 1 As shown, the agent layer S2 in this embodiment includes a planner S21, an executor S22 and a data acquisition processor S23.

[0067] (Planner S21)

[0068] Planner S21 is a module that performs decision-making functions to achieve a specific goal (or user request). It specifies a series of strategies (action plans) based on collected information and determines how to effectively achieve the goal. Specifically, in this embodiment, planner S21 is configured to receive a program performance analysis request from the user (or automatically generated by the system) for a specific target program and, upon receiving the program performance analysis request, perform the following actions:

[0069] Decompose the received program performance analysis request into multiple performance analysis tasks;

[0070] For each performance analysis task, generating static code analysis instructions; and

[0071] The generated static code analysis instruction is passed to the executor S22.

[0072] Specifically, when receiving a program performance analysis request for a target program from a user or automatically generated by the system, the planner S21 sends a program performance analysis request (for example, "The container memory usage continues to rise, and a leak is suspected. Please analyze the object growth") to a large model instance (for example, an inference model) of the large model layer S1 through a pre-designed interface.

[0073] After receiving the program performance analysis request, the inference model performs semantic understanding and intent recognition on the request, presented in natural language. It extracts key entities (such as "container") and specifies the analysis type (such as "memory object growth analysis (non-CPU or I / O issues)"). Based on this, the inference model generates a diagnostic decision tree and, based on this tree, decomposes the program performance analysis request into multiple performance analysis tasks. For example, "Container memory usage continues to rise, a leak is suspected, please analyze object growth." This can be decomposed into tasks such as "memory timing trend verification," "heap memory snapshot comparison," and "memory allocation hotspot tracking."

[0074] On this basis, the planner S21 generates a static code analysis instruction based on each performance analysis task and passes it to the executor S22 to perform subsequent actions.

[0075] It should be noted that the target program's performance analysis request can be manually entered by the user or automatically generated by the system. If manually entered by the user, it can typically be presented in natural language. Examples of natural language program performance analysis requests include: "Container memory usage continues to rise, suspecting a leak. Please analyze object growth," "The database CPU soars to 90% at 1 a.m. every day. What's going on?", and "Game loading has recently become slow. Please help me find the cause."

[0076] (Actuator S22)

[0077] Executor S22 is a module that performs specific operations based on instructions from planner S21 and other components. Executor S22 possesses both action execution and environmental interaction capabilities. "Action execution" refers to the ability of executor S22 to execute actions according to planned strategies and procedures (for example, static code analysis instructions generated by planner S21). "Environmental interaction" refers to the ability of executor S22 to interact and write with other entities (such as users, planner S21, data acquisition processor S23, large model layer S1, and toolbox layer S3).

[0078] In this embodiment, specifically, the actuator S22 is configured as follows:

[0079] Based on the static code analysis instruction received from the planner S21, the toolbox layer S3 calls a corresponding code analysis tool to analyze the source code of the target program to generate a static analysis result (the details of the static analysis result will be described later). The static analysis result includes code anchor metadata of the source code of the target program (the details of the code anchor metadata will be described later).

[0080] Based on the generated static analysis results, determine the performance data to be collected and the data collection tool to be invoked; and

[0081] A data collection instruction is generated and transmitted to the data collection processor S23. The data collection instruction includes the above-mentioned performance data to be collected and relevant information of the data collection tool to be called.

[0082] In addition, the executor S22 is further configured to handle various exceptions generated to ensure the completion of the task. In other words, the executor S22 is further configured to handle various exceptions that may cause the execution of the static code analysis instruction to fail.

[0083] (Data Acquisition Processor S23)

[0084] The data acquisition processor S23 is a module for collecting and processing the performance data of the target program when it is running. Specifically, in this embodiment, the data acquisition processor S23 is configured to:

[0085] According to the data collection instruction sent from the actuator S22, the corresponding data collection tool is called from the toolbox layer S3 to collect specific performance data, and a dynamic analysis result containing the performance data is generated (the details of the dynamic analysis result will be described later);

[0086] Based on the code anchor metadata, the dynamic analysis result is associated with the static analysis result to generate an associated analysis result (details of the associated analysis result will be described later); and

[0087] The generated correlation analysis result is passed to the report generating unit S4.

[0088] (Toolbox layer S3)

[0089] The toolbox layer S3 includes various tools for the modules of the intelligent agent layer S2 to call, such as knowledge base tools, static analysis tools (i.e., code analysis tools), dynamic analysis tools, and db tools. The knowledge base tool is used to centrally store and manage system knowledge (such as the performance analysis report described later, the above-mentioned correlation analysis results, the static analysis results, and the structured knowledge and unstructured knowledge contained in the dynamic analysis results, which will be described later). The dynamic analysis tool is used to collect and visualize the performance data of the target program at runtime. The db tool is used for persistent storage and providing time series queries, etc. It should be noted that the above tools are only examples, and the types of tools included in the toolbox layer S3 are not limited to these. Other types of tools may also be included according to actual conditions.

[0090] (Report Generator S4)

[0091] In this embodiment, the report generating unit S4 is configured to generate a program performance analysis report representing the program performance of the target program based on at least the correlation analysis results generated by the data acquisition processor (the details of the program performance analysis report will be described later).

[0092] (Knowledge Management Department S5)

[0093] The knowledge management unit S5 is used to manage the structured knowledge and unstructured knowledge in static analysis results, dynamic analysis results, correlation analysis results, and program performance analysis reports. Specifically, the knowledge management unit S5 has knowledge classification and storage functions, knowledge association and integration functions, knowledge retrieval and update functions, and knowledge application and sharing functions. The knowledge classification and storage function refers to the function of distinguishing between structured knowledge and unstructured knowledge and formulating storage rules. The knowledge association and integration function refers to the function of associating the knowledge in static analysis results, dynamic analysis results, correlation analysis results, and program performance analysis reports to form a complete knowledge graph. The knowledge retrieval and update function refers to the function of querying, versioning, updating, and eliminating stored structured and unstructured knowledge. The knowledge application and sharing function refers to the function of providing knowledge reuse capabilities (such as historical problem pattern matching, similar case recommendation, etc.) for subsequent analysis.

[0094] [One embodiment of a program performance analysis method]

[0095] The main structure of the program performance analysis system S according to one embodiment of the present application has been described above. Figure 2 , an example of a program performance analysis method based on the program performance analysis system S is described.

[0096] Figure 2 A timing diagram of a program performance analysis method according to an embodiment of the present application is shown, illustrating a round of planning.

[0097] First, in step ST001, the planner S21 in the agent layer S2 passes a received program performance analysis request to the large model layer S1. More specifically, planner S21 sends the program performance analysis request, presented in natural language, to a large model instance (e.g., an inference model) in the large model layer S1 via a pre-designed interface. The large model instance performs semantic understanding and intent recognition on the program performance analysis request presented in natural language, thereby decomposing the program performance analysis request into multiple performance analysis tasks.

[0098] In step ST002 , the large model layer S1 returns the multiple performance analysis tasks obtained by decomposition to the planner S21 .

[0099] In steps ST003 and ST004, the planner S21 generates a static code analysis instruction for each performance analysis task and passes the static code analysis instruction to the executor S22. The static code analysis instruction is used to instruct the executor S22 to call a specific static code analysis tool to analyze the source code of the target program to generate a static analysis result.

[0100] In step ST005, executor S22 determines the target program's source code to be statically analyzed and the static analysis tool to be invoked based on the received static code analysis instruction. Consequently, executor S22 invokes a specific static analysis tool (e.g., clang-tidy, ESLint, go vet, etc.) from toolbox layer S3 to analyze the target program's source code, generating a static analysis result containing code anchor metadata. Specifically, executor S22 invokes the static analysis tool (e.g., gprof, clang, etc.) from toolbox layer S3 to locate the target code to be analyzed based on the file path and code location (line number, column number) of the target program's source code file. Next, executor S22 uses the static analysis tool to extract the name of the target function in the source code, including the file path, specific line number, call chain, and code structure type. Based on the extracted code anchor metadata, executor S22 generates a static analysis result, which includes at least the extracted code anchor metadata. The purpose of code anchor metadata is to inform the executor which functions, call chains, and code locations to focus on. In fact, static analysis results include not only code anchor metadata, but also the runtime environment, dependencies, and static code analysis tool configuration information.

[0101] In step ST006, after generating the above-mentioned static analysis results, the executor S22 determines the type of performance data to be collected based on the code anchor metadata and other information contained in the static analysis results. For example, for a target function of one of the code anchor metadata, the corresponding performance data to be collected includes the number of calls, execution time, CPU usage, number of memory allocations, allocation size, leak detection, file read and write times, etc. of the target function. For another example, for a call chain of one of the code anchor metadata, the corresponding performance data to be collected includes the performance share of the call chain and the call frequency of the call chain, etc.

[0102] Furthermore, executor S22 can also determine the data collection tool (dynamic analysis tool) required to collect the performance data based on the aforementioned code anchor metadata and generate parameters for the data collection tool. In other words, executor S22 maps the aforementioned code anchor metadata to the corresponding parameters of the data collection tool. It should be noted that the "data collection tool" referred to here refers to a dynamic analysis tool (such as pprof, perf, Valgrind, VTune, etc.), whose core functions include collecting performance data while the target program is running and supporting data filtering based on context such as function name, call chain, and code line.

[0103] For example, let's use perf, a dynamic analysis tool for CPU and memory performance analysis. If the target function in the code anchor metadata is "target-function=allocateBuffer," the executor determines that the data collection tool to call is perf and maps this target function to the perf parameter "call-graph=dwarf."

[0104] In step ST007, after determining the performance data to be collected and the data collection tool to be invoked, the executor S22 generates a data collection instruction and transmits the instruction to the data collection processor S23. The data collection instruction includes at least the performance data to be collected and the relevant information of the data collection tool to be invoked, as determined above.

[0105] In step ST008, upon receiving the data collection instruction from the executor S22, the data collection processor S23 parses the data collection instruction to determine the performance data to be collected and the data collection tool to be called, and calls the corresponding data collection tool (such as the perf tool) from the toolbox layer to collect performance data.

[0106] To facilitate understanding, an example of a data acquisition instruction is listed here and analyzed.

[0107]

[0108] From the data collection instructions above, we can determine that the performance data to be collected is CPU cycles, and the corresponding data collection tool to be called is perf (a Linux performance analysis tool). In addition, the data collection instructions also specify the sampling frequency (1000Hz) and duration (5 seconds).

[0109] Taking the calling of the perf tool as an example, the data collection processor S23 enables the perf tool to collect the performance data of CPU cycles through the following command, for example.

[0110]

[0111] In step ST009, after the data collection tool completes the collection of specific performance data, the collected performance data is transmitted to the data collection processor S23. For example, after the performance data is collected, an output file (e.g., perf.data) containing the performance data is generated and transmitted to the data collection processor S23.

[0112] In step ST010, upon receiving the output file of the performance data, the data acquisition processor S23 parses the output file of the performance data to generate a dynamic analysis result. For ease of understanding, an example of the dynamic analysis result is shown here.

[0113]

[0114] in:

[0115] trace_id and span_id: Dynamically generated by the perf tool at runtime, used to identify the uniqueness and timing relationship of events.

[0116] function: The name of the function being analyzed (compute).

[0117] event_type: Performance event type (CPU cycles).

[0118] value: Performance indicator value (CPU usage: 98.76%).

[0119] call_stack: call chain (main → compute).

[0120] raw_data: raw performance data (such as sampling times and total number of cycles).

[0121] In step ST011 , when a dynamic analysis result is generated, the data acquisition processor S23 returns the dynamic analysis result to the executor S22 .

[0122] In step ST012 , upon receiving the dynamic analysis result from the data acquisition processor S23 , the executor S22 automatically associates the static analysis result with the dynamic analysis result based on the code anchor metadata to form an associated analysis result.

[0123] For example, the code anchor metadata included in the static analysis results is as follows.

[0124]

[0125] Specifically, the data acquisition processor uses the function field (compute) as a key to search for the corresponding code anchor metadata from the static mapping table, and fuses the data in the static analysis results with the data in the dynamic analysis results to form an associated analysis result. Among them, the data in the static analysis results used to fuse the data in the dynamic analysis results includes not only part or all of the code anchor metadata, but also includes operating environment information, test context information, etc. For ease of understanding, an example of an associated analysis result is shown below. However, it should be understood that the following associated analysis results are only examples, and the information or data contained therein is not limited thereto, and can be appropriately replaced, added, and deleted as needed.

[0126]

[0127] In step ST013 , when a correlation analysis result is generated, the executor S22 transmits the correlation analysis result to the report generating unit S4 .

[0128] In step ST014, the report generation unit S4 generates a program performance analysis report based on the received correlation analysis results. Specifically, the report generation unit S4 performs the following actions:

[0129] Obtain specific large model instances from the large model layer (such as performance analysis models for C / C++, GC analysis models for Java, etc.);

[0130] Encapsulate the association analysis results into prompts based on pre-set prompt templates;

[0131] Call large model APIs (such as Chatgpt, Deepseek, Tongyi Qianwen, etc.);

[0132] Obtain inference results for large models and generate program performance analysis reports.

[0133] For ease of understanding, an example of a prompt word template is shown here.

[0134]

[0135] On this basis, the corresponding data in the association analysis results are filled into the above prompt word template, thereby forming the following final prompt word.

[0136]

[0137] The aforementioned prompt is transmitted to the invoked large model instance via the API called by the executor. After receiving the prompt, the invoked large model instance performs inference and outputs a program performance analysis report. Here, an example of a program performance analysis report is provided. However, it should be noted that the generated program performance analysis report is not limited to this format; any report can be generated as long as it automatically links code logic with performance data.

[0138]

[0139] The program performance analysis report clearly points out that the performance bottleneck occurs in lines 8-13 of the compute() function in the source code of the target program, and also points out that the specific performance bottleneck is "the CPU usage of the compute() function is as high as 98.76%."

[0140] In other words, through the above method, a performance analysis conclusion can be formed that automatically associates the code logic with the collected performance data. In other words, through the above analysis method, static analysis results and dynamic analysis results can be automatically associated for analysis.

[0141] The program performance analysis report also provides a code logic analysis of the possible causes. Specifically, it points out that the nested loop in the compute() function may not be optimized, and provides specific optimization suggestions.

[0142] In addition, optionally, based on the generated program performance analysis report, a manually annotated conclusive description can be added.

[0143] The above description focuses on a single data source (CPU). However, the analysis system described in this embodiment can also perform performance analysis based on multiple data sources, namely, multimodal data (or, heterogeneous data from multiple sources). For ease of understanding, the following description uses the performance analysis of a web service application as an example.

[0144] Suppose there is a web service application (such as a Flask application based on PHP) and its performance bottlenecks need to be analyzed. The analysis objects involved include CPU performance (such as high CPU usage), memory usage (such as memory leaks), network latency (such as slow database queries), and log events (such as frequent exception throwing).

[0145] As described above, after receiving a performance analysis request from a user, the planner decomposes it into multiple performance analysis tasks (or multimodal performance analysis tasks), each corresponding to a data source. For ease of understanding, an example of a multimodal performance analysis task is shown here (described in JSON).

[0146]

[0147] Next, as described above, for each performance analysis task, the executor invokes a static code analysis tool to analyze the target program's source code and generate a static analysis result, which contains code anchor metadata. In other words, each performance analysis task corresponds to a static analysis result. Based on each static analysis result, the executor determines the performance data to be collected and the data collection tool to be invoked, and generates data collection instructions corresponding to each static analysis result. Then, based on each data collection instruction, the data collection processor invokes different data collection tools from the toolbox layer to collect performance data from different data sources, specifically, performance data of different modalities.

[0148] However, performance data from different modalities is difficult to align across time. For example, because performance data from different modalities (such as CPU utilization, memory leak rate, network latency, and log events) is collected through different data collection tools, the collection frequencies often vary significantly (for example, CPU data is collected 10 times per second, while log events are collected once per minute). Furthermore, in distributed systems, the clock sources of various data collection tools may be inconsistent. Furthermore, the collection of performance data from different modalities involves conflicts between event-driven and periodic collection. For example, it is often difficult to directly align log events (such as "database timeouts") with periodically collected performance data (such as CPU utilization) across timelines.

[0149] Time alignment strategies include hardware-level and software-level ones. Hardware-level time alignment, for example, involves deploying a PTPv2 master clock at the toolbox level, using PTPv2-supported hardware to provide a unified clock reference for all data tools. Furthermore, integrating an FPGA hardware timestamp module into the data acquisition processor eliminates software scheduling delays. Software-level time alignment strategies, such as the Dynamic Time Warping (DTW) algorithm, can be used to dynamically align asynchronously acquired performance data of different modalities (such as CPU utilization and log events). Specifically, the timestamp sequences of log events and CPU utilization are fed into the DTW algorithm, and the optimal path is calculated to interpolate the low-frequency log events onto the time axis of the high-frequency CPU utilization data. Software-level time alignment strategies can also employ timestamp interpolation compensation algorithms. Specifically, linear or spline interpolation is performed on low-frequency performance data (such as log events) to align them with the high-frequency performance data (CPU utilization) in the temporal dimension. For ease of understanding, time alignment implemented using the timestamp interpolation compensation algorithm is illustrated here.

[0150]

[0151] On the other hand, there is also the problem of difficulty in aligning performance data of different modalities in the spatial dimension. As one of the solutions, for example, the performance data of different modalities collected by different data collection tools can be mapped to the same logical space based on the common code anchor metadata contained in the static analysis results corresponding to each performance analysis task. For example, when the static analysis results corresponding to all performance analysis tasks contain the same call chain, the performance data of all modalities can be integrated together based on the call chain. However, sometimes, there is code anchor metadata that is not shared by all static analysis results. In this case, as another solution, when the program performance analysis request is decomposed into multiple performance analysis tasks, the same tracking identifier is assigned to each performance analysis task. Thus, after collecting the performance data of different modalities, while matching them with their respective code anchor metadata, they are also matched with the above-mentioned tracking identifier, so that these dynamic analysis results can be aggregated together based on the same tracking identifier to achieve alignment in the spatial dimension.

[0152] Through the above approach, when collecting and processing multimodal performance data, not only can code logic be automatically associated with performance data, but performance data from different modalities can also be automatically associated. Thus, by automatically associating code logic with performance data from different modalities, a more accurate program performance analysis report can be provided compared to when only associating with a single performance data point.

[0153] For ease of understanding, the following describes the main process of performance analysis of a test case based on the program performance analysis method described in the above embodiment.

[0154] Figure 3 A flowchart showing the main steps of the performance analysis of a test case based on the program performance analysis method described in the above embodiment is shown.

[0155] After a specific version of a target program is generated (step ST1 ), for example, by CICD (ie, continuous integration and continuous deployment), a specific test module is triggered and called to test the target program (step ST2 ).

[0156] After completing the test of the target program, a program performance analysis request is triggered to call the program performance analysis system S described in the above embodiment to perform program performance analysis of the test case (step ST3).

[0157] After triggering the above-mentioned program performance analysis request, in step ST4, the environment of the entire intelligent agent layer S2 is initialized. Environment initialization includes configuration loading, resource pre-allocation, tool chain verification, state reset, and anchor metadata template generation. Configuration loading, for example, includes loading the target program path, analysis parameters (such as sampling frequency), and tool chain configuration. Resource pre-allocation, for example, includes allocating memory and storage resources for storing static analysis results, dynamic performance data, etc. Tool chain verification, for example, includes detecting the availability and version compatibility of data acquisition tools in the toolbox layer S3. State reset, for example, includes clearing the historical task cache, ensuring the purity of the analysis environment, etc. Anchor metadata template generation, for example, includes pre-building a framework for associating code anchors with performance data. After completing the environment initialization, proceed to step S5.

[0158] In step ST5, as described in the program performance analysis method of this embodiment, the planner S21 calls the large model instance in the large model layer S1 to decompose the above-mentioned program performance analysis request into multiple program performance analysis tasks, and generates static code analysis instructions for each program performance analysis task, and passes the static code analysis instructions to the executor S22.

[0159] In step ST6, executor S22 performs specific tasks, including static code analysis and data acquisition instruction generation. Specifically, as described above, executor S22 invokes a specific static analysis tool from toolbox layer S3 based on the received static code analysis instruction to analyze the target program's source code and generate static analysis results. Furthermore, based on the code anchor metadata included in the static analysis results, executor S22 determines the performance data to be collected and the data acquisition tool to be invoked. It then generates a data acquisition instruction containing this information and transmits it to data acquisition processor S23.

[0160] In step ST7, the data acquisition processor S23 executes data acquisition and data processing tasks based on the received data acquisition instructions. Specifically, as described above, the data acquisition processor S23 invokes a specific data acquisition tool from the toolbox layer S3 to collect specific performance data of the target program during runtime and generates dynamic analysis results containing the collected performance data.

[0161] On this basis, in step ST8, the data acquisition processor S23 determines whether it is possible to automatically associate the static analysis results with the dynamic analysis results based on the code anchor metadata to form an associated analysis result. In the case where it is determined that the associated analysis result cannot be formed, information indicating that the association failed is sent to the planner S21. Upon receiving the information indicating that the association failed, the planner S21 calls the large model instance in the large model layer S1 to re-split the program performance analysis request into multiple new program performance analysis tasks, and executes each new program performance analysis task in the order of steps S6 to S8. In the case where it is determined that the associated analysis result can be formed, information indicating that the association is successful is sent to the planner S21. Upon receiving the information indicating that the association is successful, the planner S21 instructs the data acquisition processor S23 to send the associated analysis result to the report generation unit S4.

[0162] In step ST9 , the report generating unit S4 generates a program performance analysis report based on at least the received correlation analysis result.

[0163] When a program performance analysis report is generated, it indicates that the program performance analysis has been successful. In step ST10, the test is stored in the database and the analysis is ended.

[0164] [First Modification of Program Performance Analysis Method]

[0165] Next, refer to Figure 4, the first variation of the program performance analysis method of the above embodiment is described. Compared to the above embodiment, this first variation further includes step ST013A in place of step ST013, as well as steps ST013B and ST013C. Unlike step ST013, in step ST013A, when a correlation analysis result is generated, the executor S22 sends it to the planner S21 instead of the report generator S4. Next, in step ST013B, the planner S21 invokes a specific big model instance from the big model layer S1 via a predefined API interface to analyze the correlation analysis results and determine whether an analysis conclusion can be reached. Specifically, the planner S21 inputs the program performance analysis request, the correlation analysis results, and the historical task context including information such as the analysis round into the invoked big model instance for inference, determining whether an analysis conclusion can be reached. If the analysis conclusion is determined to be reached, the process proceeds to step ST014. On the other hand, if the analysis conclusion is determined to be unreachable, the process proceeds to step ST013C. In step ST013C, planner S21 passes the "unable to reach an analysis conclusion" determination, the associated analysis results, and the program performance analysis request to the large model instance of large model layer S1, generating multiple new performance analysis tasks. Then, steps ST002 through ST013B are repeated until a conclusion is reached, at which point the process proceeds to step ST014.

[0166] According to the program performance analysis method of the first variation, the accuracy of program performance analysis can be improved by performing multiple rounds of planning, compared to the case of performing only one round of planning.

[0167] [Second Modification of Program Performance Analysis Method]

[0168] Based on the above embodiment, optionally, when a program performance analysis report is generated, the executor S22 transmits the program performance analysis report, the static analysis results, the dynamic analysis results, and the correlation analysis results to the knowledge management unit S5. The knowledge management unit S5 independently stores the structured knowledge and unstructured knowledge contained in the program performance analysis report, the static analysis results, the dynamic analysis results, and the correlation analysis results. Specifically, the knowledge management unit S5 stores the structured knowledge contained in the results and report in a relational database and stores the unstructured knowledge in a vector database.

[0169] In the static analysis results, structured knowledge includes command parameters and analysis tool configuration, code anchor metadata, dependencies and call chains, execution environment and tool information, etc., while unstructured knowledge includes function descriptions, context descriptions of call chains, etc.

[0170] In the dynamic analysis results, structured knowledge includes performance data (or performance indicators) and event types, call stack information, and trace identifiers. Unstructured knowledge includes log data, exception stack trace information, user interaction records, etc.

[0171] In particular, in the program performance analysis report, structured knowledge includes target program information, operating environment information, etc., and unstructured knowledge includes analysis conclusions described in natural language (including manually added comments presented in natural language), etc.

[0172] According to the program performance analysis method described in the second variant, by separately storing structured and unstructured knowledge and combining the advantages of relational databases and vector databases, efficient management, intelligent retrieval and cross-scenario reuse of analysis results are achieved. This not only improves the comprehensiveness and accuracy of program performance analysis, but also provides a solid data foundation for automated tool chains and intelligent decision-making, ultimately significantly optimizing the efficiency and quality of software development.

[0173] [Third Modification of Program Performance Analysis Method]

[0174] Based on the above implementation, the data acquisition processor S23 optionally predefines a standardized interface based on a specific transmission protocol, which is used for hot loading of the data acquisition tools included in the toolbox layer S3. However, it should be noted that all data acquisition tools must comply with the specifications of this interface. The interface defines the rules for interaction between each data acquisition tool and the data acquisition processor, including calling methods, data exchange formats, exception handling methods, etc., to ensure that each data acquisition tool and the data acquisition processor can communicate according to a unified standard.

[0175] According to the program performance analysis method described in the third variant, using a unified, standardized interface, data collection tools can be dynamically plugged in and out as needed through the interface as plug-ins. This allows for the addition of new data sources based on actual needs by simply adding new data collection tools through hot loading to collect the new performance data, without rewriting or rewriting the original code. This improves work efficiency and enhances the robustness of program performance analysis.

[0176] [Fourth Modification of Program Performance Analysis Method]

[0177] On the basis of the above embodiment, the toolbox layer S3 optionally further includes a field detection tool (not shown). After extracting the code anchor metadata from the target program by using the static analysis tool, the executor S22 returns a prompt message to the planner S21 indicating that the static analysis has been completed. Upon receiving the prompt message from the executor S22, the planner S21 generates a field detection instruction for detecting the key fields in the code anchor metadata, and sends the field detection instruction to the executor. Upon receiving the field detection instruction, the executor S22 calls the field detection tool from the toolbox layer S3 to detect whether the key fields are missing in the code anchor metadata. Furthermore, upon detecting the missing key fields, the executor S22 calls the static analysis tool to perform a secondary analysis on the source code of the target program, extract the missing key field information, and update the code anchor metadata.

[0178] It should be noted that if the system already has complete field information (e.g., database table structure, code comments, API documentation, etc.), it can directly extract key field information. However, if the system itself cannot obtain the specific content of the field (e.g., the field value requires external data support), it cannot directly supplement it. In addition, sometimes, although the missing key field can be detected, only the name of the key field can be determined, and the specific content of the key field (such as parameter type, description, etc.) cannot be known. For example, it is detected that the function calculate_sum lacks type information for parameter a, but the parameter type is not annotated in the source code.

[0179] To this end, the toolbox layer S3 optionally also includes a Web search tool. The executor S22 is further configured to call the Web search tool from the toolbox layer S3 to perform an online search to obtain the specific information of the key field when it detects that a key field is missing and the specific information of the key field cannot be determined, and to update the code anchor metadata. For example, the executor S22 detects through the field detection tool that the type information of the parameter filepath is missing in the code anchor metadata of the source code of the target program, but because the parameter is not annotated, the metadata cannot be extracted. To this end, the executor S22 will call the Web search tool, for example, to search for parse_config function file_path parameter type, and obtain its parameter type from Github or technical documentation.

[0180] According to the program performance analysis method described in the fourth variant, it is possible to avoid the inability to automatically associate static analysis results with dynamic analysis results due to missing key fields in the code anchor metadata, thereby improving the reliability of program performance analysis.

[0181] [Fifth Modification of Program Performance Analysis Method]

[0182] Figure 5 A flowchart showing main steps in a fifth variation of the program performance analysis method according to the above embodiment.

[0183] like Figure 5 As shown, based on the above implementation, optionally, the planner S21 calls the large model instance in the large model layer S1 and / or the historical knowledge accumulation pre-stored in the knowledge base to determine whether the analysis conclusion in the program performance analysis report is reasonable.

[0184] If the analysis conclusion is determined to be unreasonable, the planner S21 prompts the user to add a user comment to the program performance analysis report, where the user comment is used to point out the reasons for the unreasonable analysis conclusion and to propose corresponding modification suggestions (step ST100 ).

[0185] After adding the user comments, the planner S21 again calls the large model instance in the large model layer S1 and / or the historical knowledge accumulation pre-stored in the knowledge base, and updates the above analysis conclusion based on the added user comments to form an updated analysis conclusion (step ST200).

[0186] On this basis, the planner S21 calls the large model instance in the large model layer S1 and / or the historical knowledge accumulation pre-stored in the knowledge base for the third time to judge whether the updated analysis conclusion is reasonable, and repeats this process until the analysis conclusion is judged to be reasonable (step ST300).

[0187] If it is determined that the updated analysis conclusion is reasonable, the program performance analysis report is updated (step ST400 ).

[0188] In addition, when storing structured knowledge and unstructured knowledge as described in the second variant, user comments that make the analysis conclusions reasonable and the analysis conclusions that become reasonable can be further stored in the vector database as new unstructured knowledge to update the knowledge base.

[0189] On the other hand, if the analysis conclusion is determined to be reasonable, planner S21 selects a decision tree corresponding to the program performance analysis report from a predefined decision tree rule library based on the analysis conclusion as the analysis decision tree (step ST500). For example, if the initial analysis conclusion includes "CPU usage is too high on lines 8-13 of the compute() function," planner S21 calls a pre-stored "CPU optimization decision tree" (e.g., "Check loop nesting → Optimize algorithm → Discard SIMD instructions") from the decision tree rule library.

[0190] Next, the planner S21 calls the large model instance in the large model layer S1 and / or the historical knowledge accumulation pre-stored in the knowledge base to determine whether each step in the called analysis decision tree is reasonable (step ST600).

[0191] When it is determined that there are unreasonable steps in the analysis decision tree, the planner S21 prompts the user to add a user comment for the unreasonable step, wherein the user comment is used to point out the reason why the step is unreasonable and listen to the corresponding modification suggestions (step ST700).

[0192] After adding the user comments, the planner S21 again calls the large model instance of the large model layer S1 and / or the historical knowledge pre-stored in the knowledge base. Based on the analysis decision tree and the added user comments, it determines whether the analysis conclusion is reasonable. This process is repeated until the analysis conclusion is determined to be reasonable (step ST800).

[0193] If the analysis conclusion is judged to be reasonable, the nodes corresponding to the steps judged to be unreasonable in the analysis decision tree are updated based on the user comments to form an updated analysis decision tree (step ST900 ).

[0194] The present application also provides a computer program product, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in various optional implementations of the above-mentioned embodiments.

[0195] It should be understood that the present invention is not limited to the exact construction described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A program performance analysis system for analyzing the performance of a target program, characterized in that: include: An agent layer, comprising a planner, an executor, and a data acquisition processor; A large model layer, the large model layer including large model instances for the agent layer to call; as well as A toolbox layer, which includes code analysis tools and data collection tools for the agent layer to call, The planner is configured to, upon receiving a program performance analysis request for the target program, call the big model instance in the big model layer to perform the following actions: Decomposing the program performance analysis request into multiple performance analysis tasks; as well as For each performance analysis task, generate static code analysis instructions, The actuator is configured to: Based on the static code analysis instruction, calling a code analysis tool from the toolbox layer to analyze the source code of the target program to generate a static analysis result, wherein the static analysis result includes code anchor metadata of the source code of the target program; as well as Determine the performance data to be collected and the data collection tool to be called based on the static analysis results, and generate a data collection instruction, wherein the data collection instruction includes relevant information of the performance data to be collected and the data collection tool to be called, The data acquisition processor is configured to: calling the data collection tool from the toolbox layer according to the data collection instruction to collect the performance data, so as to generate a dynamic analysis result including the performance data; as well as The dynamic analysis result is associated with the static analysis result based on the code anchor metadata to generate an associated analysis result.

2. The program performance analysis system according to claim 1, wherein: The system further includes a report generating unit configured to generate a program performance analysis report of the target program based at least on the correlation analysis result.

3. The program performance analysis system according to claim 1, wherein: The code anchor metadata includes at least the source code file path, line number, and code structure type of the target program.

4. The program performance analysis system according to claim 1, wherein: The data acquisition processor defines an interface for hot loading of each of the data acquisition tools, and The data collection processor is further configured to dynamically load a data collection tool corresponding to the performance data to be collected via the interface when the data collection instruction is received.

5. The program performance analysis system according to claim 1, wherein: The toolbox layer also includes field detection tools, The executor is further configured to return a prompt message indicating that the generation of the static analysis result is completed to the planner after generating the static analysis result and before generating the data collection instruction. The planner is further configured to generate a field detection instruction for detecting key fields upon receiving the prompt information, and transmit the field detection instruction to the executor, The executor is further configured to, upon receiving the field detection instruction, call the field detection tool from the toolbox layer to detect whether the key field is missing from the code anchor metadata included in the static analysis result, and In the case where it is detected that the key field is missing, the executor performs a secondary analysis on the source code of the target program, extracts information of the missing key field, and updates the code anchor metadata based on the information.

6. The program performance analysis system according to claim 5, wherein: The toolbox layer also includes a web search tool, The executor is further configured to call the Web search tool from the toolbox layer to search for the specific information of the missing key field when it is detected that the key field is missing and the specific information of the key field cannot be determined, and update the code anchor metadata based on the specific information.

7. The program performance analysis system according to claim 2, wherein: The invention also includes a knowledge management unit configured to independently store the static analysis results, the dynamic analysis results, the association analysis results, and the structured knowledge and unstructured knowledge in the program performance analysis report.

8. The program performance analysis system according to claim 1, wherein: The planner is further configured to: receiving the association analysis result; Calling the large model instance in the large model layer to judge whether an analysis conclusion can be drawn based on the association analysis result; When it is determined that the analysis conclusion cannot be obtained, the program performance analysis request is decomposed into a plurality of new performance analysis tasks based on the determination result indicating that the analysis conclusion cannot be obtained and the correlation analysis result.

9. The program performance analysis system according to claim 2, wherein: The planner is further configured to call the large model instance in the large model layer to judge whether the analysis conclusion in the program performance analysis report is reasonable. The planner is further configured to execute the following steps if it is determined that the analysis conclusion is unreasonable: The first step is to prompt the user to add a user comment to the program performance analysis report, wherein the user comment is used to point out the reasons that lead to the unreasonable analysis conclusion and to provide modification suggestions; The second step is to call the big model instance in the big model layer and update the analysis conclusion based on the user comments to form an updated analysis conclusion; The third step is to call the large model instance in the large model layer to judge whether the updated analysis conclusion is reasonable. If it is judged to be unreasonable, return to the first step; as well as The fourth step is to update the program performance analysis report if it is determined in the third step that the updated analysis conclusion is reasonable.

10. The program performance analysis system according to claim 9, wherein: The planner is further configured to execute the following steps if it is determined that the analysis conclusion or the updated analysis conclusion is reasonable: Step 5: selecting a decision tree corresponding to the program performance analysis report from a predefined decision tree rule base according to the analysis conclusion or the updated analysis conclusion as an analysis decision tree; The sixth step is to call the large model layer to judge whether each step in the analysis decision tree is reasonable. If it is judged that there is an unreasonable step in the analysis decision tree, the seventh step is entered; Step 7: prompting the user to add a user comment for the step in the analysis decision tree that is judged to be unreasonable, wherein the user comment is used to point out the reason why the step is judged to be unreasonable and propose a modification plan; In the eighth step, after the sixth step, the large model layer is called to judge whether the analysis conclusion is reasonable based on the analysis decision tree and the user comments. If it is judged to be unreasonable, the process returns to the seventh step; as well as The ninth step is to update the nodes corresponding to the steps judged to be unreasonable in the analysis decision tree when the steps are judged to be reasonable in the eighth step, so as to form an updated analysis decision tree.

11. A program performance analysis method, which analyzes the performance of a target program based on a large model-driven intelligent agent architecture, characterized in that: The large model-driven intelligent agent architecture includes: An agent layer, comprising a planner, an executor, and a data acquisition processor; A large model layer, the large model layer including large model instances for the agent layer to call; and The toolbox layer includes at least a data collection tool for collecting performance data of the target program when it is running. The program performance analysis method comprises the following steps: a decomposition step of decomposing the program performance analysis request received by the planner into a plurality of performance analysis tasks; A first instruction generation step is to enable the planner to generate a static code analysis instruction for each performance analysis task; a static result generating step, causing the executor to call a code analysis tool from the toolbox layer based on the static code analysis instruction to analyze the source code of the target program to generate a static analysis result, wherein the static analysis result includes code anchor metadata of the source code of the target program; a second instruction generating step, causing the executor to determine, based on the static analysis result, performance data to be collected and a data collection tool to be invoked, and to generate a data collection instruction, wherein the data collection instruction includes relevant information of the performance data to be collected and the data collection tool to be invoked; a dynamic result generating step, causing the data acquisition processor to call the data acquisition tool from the toolbox layer according to the data acquisition instruction to collect the performance data, so as to generate a dynamic analysis result including the performance data; and The association result generating step enables the data acquisition processor to associate the dynamic analysis result with the static analysis result based on the code anchor metadata to generate an association analysis result.

12. The program performance analysis method according to claim 11, wherein: The large model driven intelligent agent architecture also includes a report generation unit, The program performance analysis method further includes causing the report generation unit to generate a program performance analysis report based on at least the correlation analysis result.

13. The program performance analysis method according to claim 11, wherein: When the data collection instruction is transmitted to the data collection processor, the data collection processor is enabled to dynamically load a data collection tool corresponding to the performance data to be collected via an interface, wherein: The interface is predefined for hot loading of each of the data acquisition tools.

14. The program performance analysis method according to claim 11, wherein: The toolbox layer includes field detection tools, After generating the static analysis result and before generating the data collection instruction, returning a prompt message indicating that the generation of the static analysis result is completed to the planner, The planner generates a field detection instruction for detecting key fields upon receiving the prompt information, and transmits the field detection instruction to the executor. When the executor receives the field detection instruction, it calls the field detection tool from the toolbox layer to detect whether the key field is missing in the code anchor metadata included in the static analysis result, and When it is detected that the key field is missing, the executor is caused to perform a secondary analysis on the source code of the target program, extract information of the missing key field, and update the code anchor metadata based on the information.

15. The program performance analysis method according to claim 12, wherein: The large model driven intelligent agent architecture also includes a knowledge management department, When generating the program performance analysis report, the knowledge management unit is configured to independently store the static analysis results, the dynamic analysis results, the correlation analysis results, and the structured knowledge and unstructured knowledge in the program performance analysis report.

16. The program performance analysis method according to claim 11, wherein: Also includes: When the association analysis result is generated, the association analysis result is passed to the planner; The planner calls the large model instance in the large model layer to determine whether an analysis conclusion can be drawn based on the association analysis result; If it is determined that the analysis conclusion cannot be drawn, decomposing the program performance analysis request into a plurality of new performance analysis tasks based on the determination result indicating that the analysis conclusion cannot be drawn and the correlation analysis result; as well as Return and execute the first instruction generating step again until an analysis conclusion can be obtained based on the latest association analysis result.

17. A computer program product comprising a computer program, characterized in that The computer program is executed by a processor to implement the program performance analysis method according to any one of claims 11 to 16.

Images