X desktop environment display performance bottleneck positioning method

Abstract

The invention discloses an X desktop environment display performance bottleneck positioning method, and relates to the technical field of performance bottleneck positioning, a to-be-analyzed scene composed of a plurality of X Clients and an X Server is constructed, an acquisition module is constructed, the acquisition module is integrated into a sub-module of the X Server, performance data during X Server operation are acquired through the acquisition module to serve as a performance log, and the performance log is stored in the X desktop environment. Analyzing the performance log by using an analysis module to obtain a performance analysis report, positioning a performance bottleneck based on the performance analysis report, and performing optimization; according to the invention, through the acquisition module and the analysis module designed for X Server features, the display performance bottleneck of the X Server end can be quickly positioned and optimized.

Description

Technical Field

[0001] The invention relates to the technical field of performance bottleneck positioning, and in particular to a method for positioning a display performance bottleneck of an X desktop environment. Background Art

[0002] Common Linux-like operating systems generally support and use the X Window System, which is a software window system that displays in bitmap format. The X Window System uses software tools and architecture protocols to create a graphical user environment used by the operating system.

[0003] At present, there are many performance analysis tools integrated in the commonly used Linux-like systems, such as mpstat and sar, which are CPU-related performance indicator tools; vmstat and free, which are memory-related performance indicator tools; iostat and iotop, which are I / O-related performance indicator tools; netstat and tcpdump, which are network-related performance indicator tools; and top and perf, which are comprehensive performance indicator tools. However, most of these tools analyze resource bottlenecks such as CPU, memory, network, and I / O from the perspective of the operating system, and have limited analysis functions for display performance, and are basically unable to evaluate the performance of the X Window System.

[0004] Therefore, developing a method to locate the display performance bottleneck of the X desktop environment has great practical significance. Summary of the invention

[0005] The purpose of the present invention is to provide a method for locating a display performance bottleneck of an X desktop environment to solve the shortcomings of the background technology.

[0006] In order to achieve the above object, the present invention provides the following technical solution: a method for locating a display performance bottleneck of an X desktop environment, comprising:

[0007] Run the scenario to be analyzed, which consists of multiple X Clients and X Servers;

[0008] The collection module is used to collect the performance data generated during the operation of the X Server as performance logs;

[0009] Use the analysis module to analyze performance logs and generate performance analysis reports;

[0010] Locate performance bottlenecks based on performance analysis reports and perform optimization.

[0011] In a preferred embodiment, the steps of running the scene to be analyzed, which is composed of multiple XClients and X Servers, are as follows:

[0012] Multiple X Clients represent multiple client applications;

[0013] X Server is the core component of the X desktop, which is responsible for receiving drawing requests from various X Clients and using the GPU to perform corresponding graphics calculations and rendering.

[0014] In a preferred embodiment, the step of using the collection module to collect the performance data generated during the operation of the X Server as the performance log is:

[0015] The acquisition module is used as a submodule of the X Server. During the initialization phase of the X Server, the acquisition module is loaded through the configuration file when the configuration information is loaded.

[0016] After the acquisition module is loaded, the acquisition module points the drawing function of the X Server to the redirection function provided by the acquisition module, and the original drawing function is backed up to the acquisition module;

[0017] Set collection instructions and collect X Server performance data as performance logs based on the collection instructions.

[0018] In a preferred embodiment, the step of setting a collection instruction and collecting the performance data of the X Server as a performance log based on the collection instruction is as follows:

[0019] When receiving the start collection instruction, the collection module starts to collect the performance data during the running of X Server, including the running time, parameters, type and function return value of the drawing function;

[0020] When receiving the collection end instruction, the collection module stops the collection operation and generates a performance log with the collected performance data;

[0021] The situations where the collection end instruction is generated include the X Server running ends and a preset amount of performance data is collected.

[0022] In a preferred embodiment, the step of using the analysis module to analyze the performance log and generate a performance analysis report is as follows:

[0023] Analyze the function's occupied time, function call stack, and abnormal execution function based on the performance log;

[0024] The performance analysis report is obtained by analyzing the function's occupied time, function call stack, and abnormal execution function, including functions that occupy a long time, functions that are not supported by the hardware driver, and functions that return exceptions.

[0025] In a preferred embodiment, the steps of analyzing the function's occupied time, function call stack, and abnormal execution function according to the performance log are as follows:

[0026] According to the recorded time of starting and ending drawing in the performance log, count the time taken by the function;

[0027] Build a function call stack through the order of functions that start and end drawing;

[0028] By analyzing the function's parameters, types, and return values, the function's abnormal execution function is extracted.

[0029] In a preferred embodiment, the steps of locating performance bottlenecks based on the performance analysis report and optimizing are:

[0030] Conduct in-depth analysis on functions that take up a long time, functions that are not supported by the hardware driver, and functions that return exceptions in the performance analysis report;

[0031] Obtain in-depth data including GPU resources used by the function at runtime, algorithm complexity, and execution status in different call stacks;

[0032] Determine whether the function is a performance bottleneck based on deep data, and if so, execute the optimization plan;

[0033] The optimization solutions include but are not limited to optimizing data structures, caching calculation results, adopting parallel computing, function replacement, and coordinated optimization of software and hardware.

[0034] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0035] 1. The present invention realizes efficient data collection by constructing a collection module. The collection module is integrated when the XServer is initialized and can achieve efficient data collection without interfering with the normal operation of the server. It redirects the drawing function of the X Server to a custom collection function and records the performance data of the drawing process in real time, such as the function running time, parameters, type and return value. This method not only ensures the real-time and accuracy of data collection, but also ensures the stability of the system due to the backup of the original drawing function, avoiding the performance degradation caused by the collection process.

[0036] 2. The present invention constructs dynamic control of the acquisition module and can flexibly start and stop data collection through the setting of acquisition instructions, and optimize and adjust for specific test scenarios or load conditions. This flexibility enables the development team to collect performance data in a targeted manner under different workloads and accurately capture performance fluctuations. Based on this, developers can obtain detailed performance logs, which is convenient for identifying and understanding the root causes of problems in the subsequent analysis stage. The accurate and efficient acquisition mechanism provides a solid data foundation for in-depth analysis, thereby improving the accuracy of locating performance bottlenecks;

[0037] 3. The present invention can integrate multiple performance indicators and data for in-depth analysis by constructing an analysis module. By analyzing the performance log, the analysis module can extract the function's occupied time, call stack and abnormal execution function. This information is crucial to identifying performance bottlenecks. The module is not limited to basic data analysis, but can also construct a function call stack by counting the start and end time of drawing. By analyzing the execution order of the functions, the development team can understand which functions are interdependent and which functions do not perform as expected. This in-depth analysis can help the team identify potential design problems and resource consumption from the program level, and promote developers to optimize the basic code and architecture design to improve overall performance. Based on this, the analysis module can provide efficient decision support to ensure that the optimization measures are more targeted and efficient. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0039] Figure 1 The present invention is a flow chart of the method. DETAILED DESCRIPTION

[0040] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0041] Example 1, please refer to Figure 1 As shown, the method for locating the display performance bottleneck of the X desktop environment described in this embodiment includes:

[0042] S1, running the scenario to be analyzed, which consists of multiple X Clients and X Servers;

[0043] S2, using the collection module to collect the performance data generated during the operation of the X Server as a performance log;

[0044] S3, using the analysis module to analyze the performance log and generate a performance analysis report;

[0045] S4. Locate performance bottlenecks based on performance analysis reports and perform optimizations;

[0046] As described in the above steps S1-S4, common Linux-like operating systems generally support and use the X Window System, which is a software window system displayed in a bitmap format. The X Window System creates a graphical user environment used by the operating system through software tools and architecture protocols. At present, many performance analysis tools are integrated on common Linux-like systems, such as CPU-related performance indicator tools mpstat and sar; memory-related performance indicator tools vmstat and free; I / O-related performance indicator tools iostat and iotop; network-related performance indicator tools netstat and tcpdump; comprehensive performance indicator comprehensive tools top and perf. However, most of these tools analyze resource bottlenecks such as CPU, memory, network, and I / O from the perspective of the operating system, and have limited analysis functions for display performance, and are basically unable to evaluate the performance of the X Window System. The present invention realizes efficient data collection by constructing a collection module. The collection module is integrated when the X Server is initialized and can not interfere with the normal operation of the server, thereby realizing efficient data collection. It realizes efficient data collection by integrating X The drawing function of the server is redirected to a custom collection function, which records the performance data of the drawing process in real time, such as the function running time, parameters, type and return value. This method not only ensures the real-time and accuracy of data collection, but also ensures the stability of the system due to the backup of the original drawing function, avoiding performance degradation caused by the collection process. In addition, by building dynamic control of the collection module and setting the collection instructions, data collection can be flexibly started and stopped, and optimized for specific test scenarios or load conditions. This flexibility allows the development team to collect performance data in a targeted manner under different workloads and accurately capture performance fluctuations. Based on this, developers can obtain detailed performance logs, which is convenient for identifying and understanding the root cause of the problem in the subsequent analysis stage. The accurate and efficient collection mechanism provides a solid foundation for in-depth analysis. A solid data foundation is built to improve the accuracy of locating performance bottlenecks. At the same time, by building an analysis module, a variety of performance indicators and data can be integrated for in-depth analysis. By analyzing the performance log, the analysis module can extract the function's occupied time, call stack and abnormal execution function. This information is crucial to identifying performance bottlenecks. This module is not limited to basic data analysis, but can also build a function call stack by counting the start and end time of drawing. By analyzing the execution order of functions, the development team can understand which functions are interdependent and which functions do not perform as expected. This in-depth analysis can help the team identify potential design problems and resource consumption from the program level, and promote developers to optimize the basic code and architecture design to improve overall performance. Based on this, the analysis module can provide efficient decision support to ensure that the optimization measures are more targeted and efficient.

[0047] In one embodiment, the step S1 of running the scene to be analyzed, which is composed of multiple X Clients and XServers, includes:

[0048] S11. Multiple X Clients represent multiple client applications;

[0049] S12, X Server represents the core component of the X desktop, which is responsible for receiving drawing requests from each X Client and using the GPU to perform corresponding graphics calculation and rendering;

[0050] As described in the above steps S11-S12, X Client refers to an application that can send graphics drawing requests and receive feedback from XServer. For example, common X Client applications in modern X environment include word processing software such as Gedit, web browsers such as Firefox, and graphic design software such as GIMP. These applications interact with XServer through X protocol to realize the display of graphical interface. X Server plays the role of central controller of X desktop environment, responsible for all display-related hardware resource management and user input event processing. This includes interaction and coordination with display, graphics card, input devices such as keyboard and mouse. When an X Client sends a drawing request, X Server will first parse the request and determine the content of the request, including parameters such as the type, position, color, etc. of the graphics to be drawn. Then, the corresponding graphics rendering task is performed through GPU. GPU is usually programmed through driver to ensure efficient graphics processing performance, which enables complex images to be presented in real time. When multiple X Clients are running, they will compete for shared computing resources such as CPU, memory and GPU. For this reason, X Server adopts sorting and scheduling algorithms to ensure that each X Client obtains reasonable resource allocation and minimizes waiting time and response delay, thereby improving the overall performance of the system.

[0051] In one embodiment, the step S2 of using the collection module to collect the performance data generated during the operation of the X Server as the performance log includes:

[0052] S21, using the acquisition module as an X Server submodule, and loading the acquisition module through the configuration file when loading configuration information during the X Server initialization phase;

[0053] S22, after the acquisition module is loaded, the acquisition module directs the drawing function of the X Server to the redirection function provided by the acquisition module, and the original drawing function is backed up to the acquisition module;

[0054] S23, setting a collection instruction, and collecting the performance data of the X Server as a performance log based on the collection instruction;

[0055] As described in the above steps S21-S23, the acquisition module is integrated as an X Server submodule. In the initialization phase of the X Server, the system will first load a configuration file, which contains various parameter settings related to the operation of the X Server. In this configuration file, in particular, loading instructions for the acquisition module are included. These instructions specify the path of the acquisition module and the parameters required for initialization. This ensures that when the X Server is started, the system can identify and load the acquisition module. At the same time, the acquisition module can be integrated in the form of a dynamic link library or a shared library. When the X Server is started, the X Server detects the acquisition module path in the configuration file, and then uses the system's dynamic linker to load this module. After loading, the acquisition module is registered as a submodule of the X Server, so that it can be directly connected to the drawing process of the X Server. After loading the acquisition module, the original drawing function of the X Server will be redirected to the redirection function provided by the acquisition module. This redirection is achieved by rewriting the memory address or replacing the function pointer. The redirection function will first call the function provided by the acquisition module to record performance data. In the redirection process, in order to ensure that subsequent drawing operations are not affected, the X The server needs to back up the address of the original drawing function to the collection module, which means that in the redirection function, not only the performance data collection logic needs to be executed, but also the backed-up original drawing function needs to be called to perform the actual drawing operation after the data collection is completed. This backup mechanism ensures that the system can still operate normally when the performance data is collected. The redirection function will be executed every time a drawing request arrives, and record the start and end time of the request, the type of graphics drawn, the drawing parameters and other information. This method ensures that the performance data can reflect the performance of the X Server in the process of processing drawing requests in real time, and at the same time set the collection instructions to dynamically control the opening and closing of the collection module.

[0056] In one embodiment, the step S23 of setting a collection instruction and collecting the performance data of the X Server as a performance log based on the collection instruction includes:

[0057] S231, when receiving the start collection instruction, the collection module starts to collect the performance data during the running of the X Server, including the running time, parameters, type and function return value of the drawing function;

[0058] S232, when receiving the collection end instruction, the collection module stops the collection operation and generates a performance log with the collected performance data;

[0059] S233, where the collection end instruction is generated includes the X Server running ends and a preset amount of performance data is collected;

[0060] As described in the above steps S231-S233, an interface is set for the acquisition module to receive acquisition instructions from the user or the system. When the instruction is issued, the system captures the instruction through an event monitoring mechanism or a callback function. For example, the acquisition module can be triggered to start the acquisition operation through inter-process communication, signals, or API calls. After receiving the start acquisition instruction, a high-precision timestamp function is used to record the start and end time of the drawing function. When the redirection function is executed, the acquisition module will capture the parameters related to the drawing request, such as graphic coordinates, color values, size, etc. and function types such as drawing lines, filling shapes, etc. These parameter information will be stored as structured data for subsequent analysis. For each drawing function call, the acquisition module will record the return value of the function, especially abnormal situations such as error codes or abnormal states. At the same time, the acquisition module also sets an interface for receiving the end of acquisition instructions, which can be done through the same IPC or signal machine The system is implemented. Users can send this command through console commands, graphical user interface buttons or programmatic methods. When receiving the end of collection command, the collection module will perform the following operations, including cleaning up the data collection status: retrieving or resetting the data collection status and parameter settings in the memory to ensure that the previous parameters will not be affected when a new round of collection is started later, stopping data recording: undoing the redirection of the drawing function, restoring the traffic to the original drawing function, ensuring that the normal drawing process is not affected, and the collection module maintains a memory cache or ring buffer to store the performance data collected during the collection process to ensure that the system performance is not affected by the large amount of data. At the same time, a data recording file is maintained. When the buffer is full, the buffer file is copied to the data recording file, and the buffer area is cleared to ensure the integrity of the data record. After the collection is completed, the collection module will organize and format all the collected performance data into a performance log, which includes sorting and grouping the data by timestamp, drawing type and call parameters so that it can be clearly seen in the subsequent analysis, and writing the organized data to the disk in a unified format such as JSON, CSV or custom binary format to form a performance log file.

[0061] In one embodiment, the step S3 of analyzing the performance log by using the analysis module to generate a performance analysis report includes:

[0062] S31, analyzing the function's occupied time, function call stack, and abnormal execution function according to the performance log;

[0063] S32, obtaining a performance analysis report by analyzing the function's occupied time, function call stack, and abnormal execution function, including functions that occupy a long time, functions that are not supported by the hardware driver, and functions that return an exception;

[0064] As described in the above steps S31-S32, the function running time is obtained by analyzing the performance log and the function call stack is constructed, and the abnormal execution function is marked; the function occupancy time, call stack and abnormal function obtained by the analysis are summarized to generate a list for sorting, including the function with the highest occupancy time and the function with a higher calling frequency, the sorted list of occupancy time is calculated, and the top N functions with the longest occupancy time are extracted. The analysis module will analyze the number of calls of these functions to help identify performance bottlenecks, and at the same time check the compatibility of the function with the hardware driver it supports, compare the called function with the defined hardware function list, identify unsupported functions for optimization, and identify abnormal functions that may affect the performance or function of XServer by analyzing abnormal functions, and list them as the focus of the report. Finally, the analysis results are organized into a standardized report format, usually including charts, tables and text descriptions. The report content can be divided into multiple parts, such as overview, statistical data, key function analysis, abnormality monitoring, etc.

[0065] In one embodiment, the step S31 of analyzing the function's occupied time, function call stack, and abnormally executed function according to the performance log includes:

[0066] S311, counting the occupied time of the function according to the recorded time of starting and ending drawing in the performance log;

[0067] S312, constructing a function call stack according to the function sequence of starting drawing and ending drawing;

[0068] S313, extracting the abnormal execution function by analyzing the function's parameters, type, and return value;

[0069] As described in the above steps S311-S313, the analysis module first reads the call records of all drawing functions from the collected performance logs. Each record should contain at least the following fields: function name, start time, end time, related parameters and call source, etc. The read timestamp information is converted into a digital type, which can usually be converted into a time format at the millisecond or microsecond level to facilitate subsequent calculations, ensuring that the timestamp information is ordered and that each pair of start and end times can be correctly matched. A time database or data structure is used to maintain the sorting and mark the matched status. Based on this, all the records of the drawing functions are traversed to identify each pair of start time and end time, and the calculated occupied time is stored together with the corresponding function name in a data structure such as a dictionary or database to facilitate subsequent access. Furthermore, the occupied time of each function can be summarized and counted to generate statistical information such as the total occupied time, the average occupied time, the number of calls, etc. These statistical results can provide an important reference for subsequent performance analysis. At the same time, an ordered stack structure is created to store the order of function calls. The call stack is last-in-first-out, allowing dynamic management of the hierarchical relationship of functions. When a drawing function is called, the function is pushed into the stack, and relevant information such as function name, call time, parameters, etc. are recorded at the same time. The upper-level function currently called is recorded through the information attached to the call event to maintain the true state of the stack. Whenever the end of the drawing event is recorded, the top-level function record is popped from the stack. At this time, you should check whether the function in the stack is a valid end drawing call to ensure the integrity and accuracy of the stack. Build the corresponding function call chain through the order of the stack, record the call path for each function, that is, adjacent functions become parent-child relationships, and record the hierarchical structure. After all records are traversed, the stored call stack information is combined with the occupied time data to form a hierarchical relationship of function calls, which is convenient for analyzing which functions call other functions and their mutual influence. At the same time, the analysis module extracts the parameter and return value information of each function through the fields in the performance log. A dictionary of function parameters and return values ​​can be established, recording the function name as the key, the parameter list and the return value as the value, and defining the exception standard. Functions that meet the exception standard are marked as abnormal execution functions, and the relevant information of all abnormal execution functions is listed in a centralized manner, including function name, parameter value, return value, etc.; more can be considered to combine the specific information of the abnormal execution function with the function call stack to generate a detailed tracking log for subsequent optimization and repair.

[0070] In one embodiment, the step S4 of locating performance bottlenecks based on the performance analysis report and performing optimization includes:

[0071] S41, conducting in-depth analysis on the functions that occupy a long time in the performance analysis report, the functions that are not supported by the hardware driver, and the X Client that returns an abnormal execution function;

[0072] S42, obtaining deep data including GPU resources occupied by the function during runtime, algorithm complexity, and execution status in different call stacks;

[0073] S43, judging whether the function is a performance bottleneck based on the deep data, and if so, executing the optimization plan;

[0074] S44, wherein the optimization scheme includes but is not limited to optimizing data structure, caching calculation results, adopting parallel computing, function replacement and software and hardware collaborative optimization;

[0075] As described in the above steps S41-S44, the following types of functions are extracted from the performance analysis report, including functions that take a long time: set a threshold, such as the top 20% of time-consuming functions, functions that are not supported by the hardware driver: obtain the characteristic information of these functions from the report, and return abnormal execution functions: confirm from the report according to the abnormal mark, these target functions will become the focus of further in-depth analysis. For each screened function, collect its relevant context information during the calling process, including the calling source, input parameters, return value and its calling frequency, etc., and conduct in-depth analysis on these functions, using tools or APIs such as Performance Profiler monitors the consumption of GPU resources during the execution of functions, collects relevant data such as GPU utilization, memory bandwidth, rendering time, etc., and generates GPU performance reports, including frame rate, GPU load and memory usage. At the same time, it analyzes the time complexity and space complexity of the algorithm implementation of the function, and determines whether there is a possibility of optimization by theoretically analyzing the complexity of the algorithm and combining it with the performance data of the actual runtime. It also extracts the call contexts in which the function performs poorly by analyzing the execution in different call stacks, paying special attention to the repeated resource usage caused by high call frequency, focusing on the performance of functions in multi-layer nesting, identifying potential call chain bottlenecks, and based on this Whether a function is a performance bottleneck can be determined by formulating performance evaluation criteria. For example, the threshold can be set as the function's occupancy time exceeding a certain percentage, resource usage exceeding a certain upper limit such as 80% GPU usage, or based on the frequency of abnormal execution, etc., or the collected deep data can be comprehensively evaluated to confirm whether the following situations exist: the execution time is long and the resource usage is obvious, it appears repeatedly in a specific call chain, causing other functions to be affected, and continuous errors or exceptions affect the user experience. If the function is confirmed to be a performance bottleneck, the decision will be adjusted in the subsequent optimization. The optimization plan includes but is not limited to optimizing data structures, caching calculation results, adopting parallel computing, function replacement, and software and hardware collaborative optimization.

[0076] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A method for locating a display performance bottleneck of an X desktop environment, characterized by: Run the scenario to be analyzed, which consists of multiple X Clients and X Servers; The collection module is used to collect the performance data generated during the operation of the X Server as performance logs; Use the analysis module to analyze performance logs and generate performance analysis reports; Locate performance bottlenecks based on performance analysis reports and perform optimization.

2. The method for locating the display performance bottleneck of an X desktop environment according to claim 1, characterized in that: The step of using the collection module to collect the performance data generated during the operation of the X Server as the performance log is as follows: The acquisition module is used as a submodule of the X Server. During the initialization phase of the X Server, the acquisition module is loaded through the configuration file when the configuration information is loaded. After the acquisition module is loaded, the acquisition module points the drawing function of the X Server to the redirection function provided by the acquisition module, and the original drawing function is backed up to the acquisition module; Set collection instructions and collect X Server performance data as performance logs based on the collection instructions.

3. The method for locating the display performance bottleneck of an X desktop environment according to claim 2, characterized in that: The steps of setting the collection instruction and collecting the performance data of the X Server as the performance log based on the collection instruction are as follows: When receiving the start collection instruction, the collection module starts to collect the performance data during the running of X Server, including the running time, parameters, type and function return value of the drawing function; When receiving the collection end instruction, the collection module stops the collection operation and generates a performance log with the collected performance data; The situations where the collection end instruction is generated include the X Server running ends and a preset amount of performance data is collected.

4. The method for locating the display performance bottleneck of an X desktop environment according to claim 1, characterized in that: The steps of using the analysis module to analyze the performance log and generate a performance analysis report are as follows: Analyze the function's occupied time, function call stack, and abnormal execution function based on the performance log; The performance analysis report is obtained by analyzing the function's occupied time, function call stack, and abnormal execution function, including functions that occupy a long time, functions that are not supported by the hardware driver, and functions that return exceptions.

5. The method for locating the display performance bottleneck of an X desktop environment according to claim 4, characterized in that: The steps to analyze the function's occupied time, function call stack, and abnormal execution function based on the performance log are as follows: According to the recorded time of starting and ending drawing in the performance log, count the time taken by the function; Build a function call stack through the order of functions that start and end drawing; By analyzing the function's parameters, types, and return values, the function's abnormal execution function is extracted.

6. The method for locating the display performance bottleneck of an X desktop environment according to claim 1, characterized in that: The steps of locating performance bottlenecks based on the performance analysis report and optimizing are as follows: Conduct in-depth analysis on functions that take up a long time, functions that are not supported by the hardware driver, and functions that return exceptions in the performance analysis report; Obtain in-depth data including GPU resources used by the function at runtime, algorithm complexity, and execution status in different call stacks; Determine whether the function is a performance bottleneck based on deep data, and if so, execute the optimization plan; The optimization solutions include but are not limited to optimizing data structures, caching calculation results, adopting parallel computing, function replacement, and coordinated optimization of software and hardware.

Images