Application performance optimization method, device and system, equipment and medium

Abstract

The invention provides an application performance optimization method and device, equipment and a medium, and is applied to the technical field of performance optimization. The method comprises the following steps: acquiring a CPU occupancy rate of to-be-tested equipment in a process that the to-be-tested application is operated by the test equipment; determining a target scene of the to-be-tested application according to the CPU occupancy rate, wherein the CPU occupancy rate of the to-be-tested application in the target scene meets a first preset condition; obtaining a target hardware index cached in the test equipment in the target scene, wherein the target hardware index is an index related to time consumption; under the condition that the target hardware index does not meet a second preset condition, a to-be-optimized function is determined in a target function set, and the target function set comprises a function corresponding to the target scene; and executing the optimization strategy for the to-be-optimized function to optimize the performance of the to-be-tested application. According to the application, the richness of the to-be-optimized point is improved, so that more optimization space is provided for performance optimization of the to-be-tested application, and the optimization efficiency of the to-be-tested application is improved.

Description

Technical Field

[0001] This application relates to the field of performance optimization technology, and in particular to a method for determining response time, an application performance optimization device, an electronic device, and a computer-readable storage medium. Background Technology

[0002] During application development, developers collect performance data on application versions undergoing optimization. If the current application version exhibits high CPU usage, a debug version is built and the Stat() function is recorded. The Stat() function is a widely used system call in C programming and many Unix-like operating systems (such as Linux and macOS) to obtain status information related to files or file system objects. Furthermore, the recording results are used to identify functions that consume excessive time, thus pinpointing potential areas for optimization. Summary of the Invention

[0003] This application provides an application performance optimization method, an application performance optimization device, an electronic device, and a computer-readable storage medium, which can enrich the ways to determine the points to be optimized and help improve the optimization efficiency of the application under test.

[0004] In a first aspect, embodiments of this application provide a performance optimization method for an application. The method includes: during the operation of an application under test on a test device, obtaining the CPU utilization rate of the central processing unit (CPU) of the test device; determining a target scenario for the application under test based on the CPU utilization rate, wherein the CPU utilization rate of the application under test in the target scenario satisfies a first preset condition; obtaining target hardware metrics cached in the test device in the target scenario, wherein the target hardware metrics are time-related metrics; if the target hardware metrics do not satisfy a second preset condition, determining a function to be optimized from a set of target functions, wherein the set of target functions includes functions corresponding to the target scenario; and executing an optimization strategy for the function to be optimized to optimize the performance of the application under test.

[0005] In an exemplary embodiment, based on the above scheme, the above-mentioned acquisition of the target hardware metrics cached in the test device under the target scenario includes: acquiring the target hardware metrics cached in the test device through a hardware performance counter; and, at the timestamp of the target scenario, capturing the information acquired by the hardware performance counter to obtain the target hardware metrics cached in the test device under the target scenario.

[0006] In an exemplary embodiment, based on the above scheme, before capturing the information obtained by the hardware performance counter based on the timestamp of the target scenario, the method further includes: loading the source file of the hardware performance counter into the startup module of the engine of the application under test in the form of a counting module, so as to load the counting module in the pre-initialization stage of the engine startup process.

[0007] In an exemplary embodiment, based on the above scheme, before capturing the information obtained by the hardware performance counter based on the timestamp of the target scenario, the method further includes: adding a counting group for the hardware performance counter in the performance statistics system of the engine of the application under test, so as to classify and manage the target hardware indicators obtained by the hardware performance counter; and registering the statistical category used to store the target hardware indicators to the counting group, wherein the target hardware indicators include: cache miss data, or cache miss data and cache hit data.

[0008] In an exemplary embodiment, based on the above scheme, the above-mentioned information obtained by capturing the hardware performance counter based on the timestamp of the target scenario to obtain the target hardware indicators cached in the test device under the target scenario includes: capturing the registered data in the counting group based on the timestamp of the target scenario to obtain a measurement sample package, so as to obtain the target hardware indicators cached under the target scenario; wherein, the timestamp of the target scenario is the difference between the current time point and the start time point of the application under test.

[0009] In an exemplary embodiment, based on the above scheme, the target hardware metric includes: the number of cache misses; when the target hardware metric does not meet the second preset condition, determining the function to be optimized in the target function set includes: when the number of cache misses is greater than the first preset threshold, determining the function to be optimized in the target function set according to the cache miss ratio of each function in the target function set.

[0010] The aforementioned target hardware metrics include: the number of cache misses and the number of cache hits. When the aforementioned target hardware metrics do not meet the second preset condition, determining the function to be optimized in the target function set includes: when the number of cache misses is greater than a first preset threshold, or when the ratio of the number of cache misses to the number of cache hits is greater than a second preset threshold, determining the function to be optimized in the target function set based on the cache miss percentage of each function in the target function set; wherein the cache miss percentage is the ratio between the number of cache misses of a function and the total number of cache misses in the aforementioned target scenario.

[0011] In an exemplary embodiment, based on the above scheme, determining the function to be optimized in the target function set according to the cache miss rate of each function in the target function set includes: obtaining the CPU utilization rate of each function in the target function set when the target hardware indicator does not meet the second preset condition; and determining the function to be optimized in the target function set according to the CPU utilization rate of each function; wherein the function to be optimized is a function whose CPU utilization rate is greater than a third preset threshold, or the N functions with the largest CPU utilization rate in the target function set are the functions to be optimized, where N is a positive integer.

[0012] In an exemplary embodiment, based on the above scheme, before executing the optimization strategy for the function to be optimized to optimize the performance of the application under test, the method further includes: obtaining the start position of the stack frame where the target function is located in the target function set, and obtaining the end position of the stack frame where the target function is located, wherein the target function is any function in the target function set; determining the call sequence of the target function based on the start and end positions of the stack frame; and performing symbolic parsing on the call sequence to obtain readable function information about the target function.

[0013] In an exemplary embodiment, based on the above scheme, obtaining the starting position of the stack frame where the target function is located in the target function set includes: determining the function address of the target function; and determining the starting position of the stack frame where the target function is located by the return value of the first function, wherein the first function is determined by the function address of the target function.

[0014] In an exemplary embodiment, based on the above scheme, obtaining the end position of the stack frame where the target function is located includes: obtaining the stack frame attributes of the thread where the target function is located through a second function, wherein the stack frame attributes of the thread include the stack frame range of the thread; and determining the end position of the stack frame where the target function is located based on the start position of the stack frame where the target function is located and the stack frame range of the thread.

[0015] In an exemplary embodiment, based on the above scheme, the symbolic parsing of the above call sequence includes: setting an address dictionary, wherein the address dictionary includes the correspondence between function addresses and function names; and, according to the address dictionary, performing symbolic parsing on the above call sequence to replace the function addresses in the above call sequence with the corresponding function names.

[0016] In an exemplary embodiment, based on the above scheme, the above-mentioned execution of the optimization strategy for the function to be optimized to optimize the performance of the application under test includes: performing at least one of the following optimization strategies on the function to be optimized: resource reset and optimized resource reading to optimize the performance of the application under test.

[0017] Secondly, a performance optimization device for an application is provided, comprising: a first acquisition module, a first determination module, a second acquisition module, a second determination module, and an optimization module; wherein the first acquisition module is used to acquire the CPU utilization rate of the central processing unit of the device under test during the operation of the application under test on the test device; the first determination module is used to determine the target scenario of the application under test based on the CPU utilization rate, wherein the CPU utilization rate of the application under test in the target scenario meets a first preset condition; the second acquisition module is used to acquire the target hardware indicators cached in the test device in the target scenario, wherein the target hardware indicators are time-related indicators; the second determination module is used to determine the function to be optimized from the set of target functions when the target hardware indicators do not meet the second preset condition, wherein the set of target functions includes functions corresponding to the target scenario; and the optimization module is used to execute an optimization strategy for the function to be optimized to optimize the performance of the application under test.

[0018] Thirdly, an electronic device is provided, including a processor and a memory; the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to perform the performance optimization method of the application provided by the first aspect or its various implementations.

[0019] Fourthly, a chip is provided, the chip comprising: a processor for retrieving and running a computer program from memory, causing a device equipped with the chip to perform a performance optimization method for an application as provided in the first aspect or its various implementations.

[0020] Fifthly, a computer-readable storage medium is provided for storing a computer program that causes a computer to execute the performance optimization method for the application provided in the first aspect or its various implementations.

[0021] In a sixth aspect, a computer program product is provided, including computer program instructions that cause a computer to execute the performance optimization method for the application provided in the first aspect or its various implementations.

[0022] In a seventh aspect, a computer program is provided that, when run on a computer, causes the computer to perform the performance optimization method for the application provided in the first aspect or its various implementations.

[0023] In summary, the solution provided in this application involves running the application under test on a test device and obtaining the CPU utilization rate of the test device. The application under test scenario where the CPU utilization rate meets a first preset condition (e.g., high CPU utilization) is identified as the target scenario. Then, target hardware metrics cached in the test device under the target scenario are obtained, where the target hardware metrics are time-related metrics. Further, if the target hardware metrics do not meet a second preset condition, a function to be optimized is determined from a set of target functions, where the set of target functions comprises all functions corresponding to the target scenario. The performance of the application under test is then optimized based on the function to be optimized. While related technologies do not provide a solution for determining the function to be optimized based on cached hardware metrics, this application can overcome the aforementioned deficiencies in related technologies. By obtaining the cached target hardware metrics under the target scenario and determining the function to be optimized when the target hardware metrics do not meet preset conditions, it is beneficial to improve the richness of optimization points, thereby providing more optimization space for the performance optimization of the application under test and ultimately improving the optimization efficiency of the application under test. Attached Figure Description

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

[0025] Figure 1 This is a flowchart illustrating the performance optimization method used in the related technologies of this application;

[0026] Figure 2 A schematic diagram of the architecture of an application performance optimization system provided in this application embodiment;

[0027] Figure 3 A flowchart illustrating the performance optimization method for the application provided in this embodiment of the application;

[0028] Figure 4 A flowchart illustrating the method for obtaining target hardware metrics in an embodiment of this application is shown.

[0029] Figure 5 A schematic diagram of the target hardware metrics cached in the test device provided in the embodiments of this application;

[0030] Figure 6 A flowchart illustrating the method for determining the function to be optimized provided in an embodiment of this application;

[0031] Figure 7 A schematic diagram showing the CPU usage of the function provided in the embodiments of this application during its execution;

[0032] Figure 8 A flowchart illustrating the method for symbolic parsing of function call sequences provided in this application embodiment;

[0033] Figure 9 This is a schematic diagram of the stack frame structure in memory provided in an embodiment of this application;

[0034] Figure 10 A schematic diagram of the structure of the performance optimization device for the application provided in the embodiments of this application;

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

[0036] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0037] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in sequences other than those illustrated or described herein. In embodiments of this application, "B corresponding to A" means that B is associated with A. In one implementation, B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0038] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0039] In game application development, time-consuming optimization is a crucial task, directly impacting game smoothness, responsiveness, and user experience. For example, performance analysis tools (such as Unreal Engine and UnityProfiler) can be used to analyze code performance, identifying functions or modules with excessively long execution times, and then implementing targeted optimizations.

[0040] For example, Figure 1 This is a flowchart illustrating the performance optimization method used in the related technologies of this application. Since a longer execution time for a function or method during application operation may lead to increased CPU utilization, the target scenarios with high CPU utilization can be identified first, and then targeted optimizations can be performed for these scenarios. (Reference) Figure 1In step S1, performance data is collected on the current application development and improvement version to determine if there are any target scenarios with excessively high CPU utilization. In step S2, target scenarios with excessively high CPU utilization in the current application development and improvement version are identified, allowing for targeted optimization of these target scenarios. For example, a debug version containing detailed performance statistics can be built next, recording the execution time of each function to identify those functions that take a particularly long time or are frequently called and consume a lot of resources. Game engines, such as Unity and Unreal Engine, have built-in performance profiling tools that can collect various performance data during game runtime, including CPU time, GPU time, memory usage, and DrawCall counts, in real time or offline, and can delve into the specific script function level, displaying each function call and its execution time. Developers can analyze this data to identify which functions may be performance bottlenecks and perform targeted optimizations on these functions, which may include algorithm optimization, reducing unnecessary computation, rationally scheduling tasks, and improving data structure design. In step S3, the relevant technology typically involves recording the Stat() function. In Unity, the Profiler tool can be used to record Stat functions, providing a visual view of the function call hierarchy and CPU consumption distribution per frame, thus identifying optimization points. Unreal Engine also offers a similar Profiler feature to help developers do the same. Therefore, in step S4, functions with excessively long execution times are identified as optimization points. It's evident that related technologies neglect the correlation between certain hardware metrics related to caching and CPU utilization (e.g., high cache misses likely indicate high CPU utilization). Consequently, the methods for identifying optimization points in these technologies are simplistic, hindering a comprehensive identification of optimization opportunities and ultimately reducing the efficiency of application performance optimization.

[0041] Continue to refer to Figure 1 In step S5, the functions with excessively long processing times are analyzed for potential optimization points, and corresponding trial optimizations are performed. Exemplary optimization methods in related technologies include: reducing the running frequency of the aforementioned excessively time-consuming functions, reducing the processing quantity of the aforementioned functions, etc. This results in a new improved version of the game resources (step S6). Furthermore, a new round of iterative optimization is performed based on the new improved version of the game resources, such as... Figure 1 Steps S1-S6 are shown in the figure.

[0042] As mentioned earlier, current technologies generally only utilize engine-built-in performance profiling tools (such as the Stat() function) to identify time-consuming functions as optimization points. This ignores the correlation between certain hardware metrics related to caching and CPU utilization, resulting in a simplistic approach to identifying optimization points and hindering a comprehensive assessment. Furthermore, since these technologies do not provide reasons for the excessive time consumption of these optimization points, they typically only employ lossy optimization methods (such as reducing the execution frequency of the time-consuming functions or decreasing the processing load) for tentative optimization. Therefore, these approaches may degrade the quality of games and other applications, negatively impacting the user experience.

[0043] This application's embodiments address the aforementioned technical problems in related technologies. Specifically, after determining a target scenario where the CPU utilization rate in the application under test meets a first preset condition (e.g., high CPU utilization), target hardware metrics cached under the target scenario are obtained, where the target hardware metrics are time-related metrics. Further, if the target hardware metrics do not meet a second preset condition, a function to be optimized is determined from a set of target functions, where the set of target functions comprises all functions corresponding to the target scenario. The performance of the application under test is then optimized based on the function to be optimized. Related technologies do not provide a scheme for determining the function to be optimized based on cached hardware metrics. This application's embodiments overcome the aforementioned deficiencies in related technologies by obtaining target hardware metrics for the cache under the target scenario and determining the function to be optimized when the target hardware metrics do not meet preset conditions. This improves the richness of optimization points, providing more optimization space for the performance optimization of the application under test, and thus improving the optimization efficiency of the application under test. Meanwhile, since the embodiments of this application can clearly identify the specific reasons for the excessive time consumption of the optimization point (such as a high cache miss rate), targeted optimization methods are provided (for example, the optimization methods used when the cache miss rate is too high may include resource reset or optimized resource reading, etc.). Compared with the lossy optimization methods used in related technologies, the optimization scheme provided by the embodiments of this application can effectively avoid the impact on the user experience.

[0044] In this embodiment, the cache is used to cache memory data. Data that the CPU needs to access is cached in the cache, called a "hit," and conversely, it is called a "miss." The speed at which the CPU accesses the cache is between that of registers and main memory, specifically differing by orders of magnitude. Existing CPU caches can be subdivided into several layers, generally including L1 Cache, L2 Cache, and L3 Cache, with read / write latency increasing sequentially and implementation costs decreasing sequentially.

[0045] The following is through Figure 2 The implementation environment of the embodiments of this application will be described.

[0046] For example, Figure 2 This is a schematic diagram of the architecture of a performance optimization system for an application provided in an embodiment of this application. Figure 2 As shown, the performance optimization system used in this embodiment may include: computing device 20 and testing device 22.

[0047] In an exemplary embodiment, the test device 22 can be used to run the application under test. The computing device 20 can acquire performance data of the test device during the operation of the application under test, and further determine optimization points based on the acquired performance data. For example, the computing device 20 acquires performance data of the test device 20 during the operation of the application under test, and further determines a target scenario where the CPU utilization rate meets a first preset condition based on the performance data. The computing device 20 then acquires the target hardware metrics cached by the test device 20 in the target scenario when running the application under test. Further, if the computing device 20 determines that the target hardware metrics do not meet a second preset condition, it determines a function to be optimized from a set of target functions, wherein the set of target functions is the function corresponding to the target scenario. Next, the performance of the application under test can be optimized by the computing device 20 based on the function to be optimized, or the performance of the application under test can be optimized by other computing devices based on the function to be optimized.

[0048] The aforementioned testing device 22 can be a computer, smartphone, tablet, intelligent voice interaction device, smart home appliance, vehicle terminal, aircraft, wearable smart device, medical device, etc. The testing device 22 is often equipped with a display device, which can be a monitor, display screen, touch screen, etc., and the touch screen can be a touch screen, touch panel, etc., but is not limited to these. The aforementioned computing device 20 can be a computer, tablet, or other device with computing capabilities. This computing device can include information input components and information output components (such as a display screen); the input components can input a first preset condition regarding CPU utilization, a second preset condition regarding target hardware indicators, and the output components can display the performance parameters of the testing device, etc. The aforementioned computing device 20 can also be a cloud server, specifically providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms; furthermore, the aforementioned computing device 20 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers.

[0049] For example, the test device 22 and the computing device 20 can be connected by a wired communication link, a wireless communication link, or a fiber optic cable, etc. This application embodiment does not impose any limitations. For example, the test device 22 and the computing device 20 can be connected via a Universal Serial Bus (USB).

[0050] It should be noted that, Figure 2 The system architecture of the implementation environment of the embodiments of this application is illustrated, but the system construction of the implementation environment of the embodiments of this application is not limited to... Figure 2 As shown.

[0051] The technical solutions of the embodiments of this application will be described in detail below through some examples. The following embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0052] Figure 3 This is a flowchart illustrating the performance optimization method P300 provided in this application embodiment. The execution entity of method P300 can be as follows: Figure 2 The computing device 20 can also be an electronic device with computing capabilities, such as... Figure 11 The electronic device 1100 is shown. In this embodiment, a computing device 20 is used as the execution subject for description. (See reference...) Figure 3 Method P300 includes S310 to S350.

[0053] In step S310, during the process of running the application under test on the test device, the CPU utilization rate of the central processing unit of the test device is obtained.

[0054] In an exemplary embodiment, the application under test can be any application that needs improvement. This application embodiment is used to improve application latency; therefore, the application under test can specifically be a real-time application or a game application with high real-time requirements.

[0055] In an exemplary embodiment, if the CPU remains within a function for an extended period during application execution, it means that the CPU is primarily busy processing calculations or logical judgments related to that function during that time, leaving no free time to handle other tasks. Especially in a single-threaded environment, if the function does not release CPU control (e.g., does not wait for I / O operations or other synchronization mechanisms), the CPU utilization will remain high. In a multi-threaded or multi-process environment, even if other threads can execute in parallel, if one or more threads' functions take too long and frequently consume CPU resources, the overall CPU utilization may remain high, especially in multi-core CPUs. If these threads primarily run on a few cores, the CPU utilization will also appear high. In other words, the longer a function or method takes to execute during application execution, the higher the CPU utilization may be. Therefore, this embodiment can first identify scenarios with high CPU utilization (denoted as the target scenario) and then perform targeted optimization for the target scenario.

[0056] In an exemplary embodiment, during the operation of the application under test, the computing device 20 can determine the current CPU utilization by collecting performance data in real time. For example, the PerDog tool can be used for performance data collection. PerDog primarily serves mobile application and game developers, enabling real-time and accurate acquisition and analysis of iOS and Android devices (such as...). Figure 1 The performance data shown on the test device 22) includes various performance indicators such as CPU, GPU, memory, power consumption, frame rate, network traffic, and startup time. Using the PerfDog tool, developers can directly connect to a mobile phone or tablet to visualize and control performance data, and record performance data trajectories. This facilitates the analysis of performance bottlenecks during application operation, optimizes product performance, and improves user experience.

[0057] Continue to refer to Figure 3 Method P300 further includes step S320: determining the target scenario of the application under test based on the CPU utilization rate, wherein the CPU utilization rate of the application under test in the target scenario meets a first preset condition.

[0058] In an exemplary embodiment, the aforementioned first preset condition may be a pre-set CPU utilization threshold, such as 90%, 85% to 95%, etc. It is understood that the aforementioned first preset condition can be determined according to actual needs, and different thresholds can be set according to different applications under test or different hardware configurations of the test equipment. Furthermore, in different tests of the same application under test using the same test equipment, different first preset conditions can be set according to different test requirements; this application embodiment does not limit this.

[0059] In this embodiment, the application under test is run on the test device 22, and performance data during the running process is obtained by the computing device 20. For example, the computing device 20 obtains the CPU utilization rate of the test device 22 using a performance monitoring device. Further, based on the CPU utilization rate data of the terminal during the running process of the application under test, the computing device 20 determines one or more scenarios where the utilization rate meets a first preset condition, which are denoted as target scenarios in this embodiment. Through the above method, the computing device 20 can efficiently locate the target scenarios in the application under test, and then optimize the time consumption of the target scenarios through the following embodiments.

[0060] Continue to refer to Figure 3 Method P300 further includes step S330: obtaining target hardware metrics cached in the test device under the target scenario, wherein the target hardware metrics are time-related metrics.

[0061] Since there is a correlation between some hardware metrics of the cache and CPU utilization, the solution provided in this application will determine the function to be optimized that causes high CPU utilization based on the target hardware metrics of the cache, thereby enriching the way to determine the optimization point.

[0062] In an exemplary embodiment, Figure 4 The flowchart illustrating the method for obtaining target hardware indicators in an embodiment of this application is shown and can be used as a specific implementation of S320.

[0063] refer to Figure 4 In step S320-1, a hardware performance counter is loaded. Specifically, in this embodiment, the target hardware metrics cached in the test device are obtained through the hardware performance counter.

[0064] Hardware metrics can typically be obtained and analyzed using tools provided by the operating system, performance analyzers, or specific hardware performance counters. For example, the Hardware Counter Pipeline (HWCPipe) can be used to collect and analyze CPU and GPU hardware performance metrics. With HWCPipe, developers can easily obtain data from hardware performance counters, such as cache misses, CPU branch prediction failures, and GPU shader execution counts.

[0065] In an exemplary embodiment, the source file of the hardware performance counter HWCPipe is loaded as a counter module into the startup module of the application under test's engine, so as to load the aforementioned counter module during the pre-initialization phase of the engine startup process. By directly loading HWCPipe as an engine module into the engine's startup module (LoadPreInitModules), it is beneficial to facilitate subsequent acquisition of counter data. For example, the implementation code in the game engine development environment is as follows:

[0066] Void FEngineLoop::LoadPreInitModules()

[0067] {

[0068] FModuleManager::Get().LoadModule(TEXT(HWCPipe))

[0069] }

[0070] The above implementation code is used to load a module named "HWCPipe" during the engine's pre-initialization phase for use during subsequent engine operation. `FEngineLoop::LoadPreInitModules` is a function responsible for loading necessary modules during the pre-initialization phase of the engine startup process. `FModuleManager` is a class that manages module loading and unloading; its `Get()` function is typically used to obtain a singleton instance, which is then used to call the `LoadModule()` function to load the module. `TEXT(HWCPipe)` is a macro used to convert a string constant to a wide character string to adapt to different platform string types; here, "HWCPipe" is the name of the module to be loaded.

[0071] refer to Figure 4 In step S320-2, the target hardware metrics to be collected are configured. Specifically, after configuring the aforementioned hardware performance counters, the data to be collected (i.e., the target hardware metrics) is then configured.

[0072] For example, in the performance statistics system of the application under test's engine, groups (e.g., count groups) for the hardware performance counters are added. This allows for the classification and management of the target hardware metrics obtained from the hardware performance counters through these count groups. The game engine's Stat system is a tool for collecting, analyzing, and visualizing game runtime performance data. The Stat system primarily obtains game performance metrics such as CPU and GPU utilization, memory usage, network bandwidth, physics simulation performance, draw calls, rendering frame rate, scene loading time, resource loading and unloading efficiency, particle system efficiency, AI computation time, and game logic execution time. The Stat system typically provides a way to detect and measure these metrics and presents them to developers in real-time in the form of charts or numerical values. Developers can quickly identify performance bottlenecks and optimization points during game execution by observing these statistics, enabling effective performance optimization. For example, in the Unity engine, developers can use the Profiler tool to obtain detailed performance statistics; in Unreal Engine, they can use the Stat command-line tool and the built-in performance analyzer to monitor and analyze various performance metrics in real time. In this embodiment of the application, a new counting group is added to the Stat system. For example, the counting group can be represented as STATGROUP_HWCPipe, which is used to classify the data attributes obtained from all hardware performance counters.

[0073] In an exemplary embodiment, a statistical category for storing the target hardware metric is registered to the counting group. For example, the target hardware metric to be acquired includes: cache miss data, or cache miss data and cache hit data. When the target hardware metric to be acquired includes the number of cache misses and the number of cache hits, two statistical categories can be registered, such as STAT_L1DataCacheAccess and STAT_L1DataCacheRefill. Specifically, based on the classification results of various hardware acquisition data obtained from the hardware performance counters of the technical group, for example, L1 Data CacheAccess is added to the hardware statistical counter group, with the statistical category being STAT_L1DataCacheAccess; or, for example, L1 Data Cache Refill is added to the hardware statistical counter group, with the statistical category being STAT_L1DataCacheRefill. For example, the implementation code in the game engine development environment is as follows:

[0074] DECLARE_STATS_GROUP(TEXT("HWCPipe"),STATGROUP_HWCPipe,STATCAT_Advanced);

[0075] DECLARE_FLOAT_COUNTER_STAT(TEXT("L1 Data Cache Access"),

[0076] STAT_L1DataCacheAccess,STATGROUP_HWCPipe);

[0077] DECLARE_FLOAT_COUNTER_STAT(TEXT("L1 Data Cache Refill"),

[0078] STAT_L1DataCacheRefil1,STATGROUP_HWCPipe);

[0079] The code above declares and registers a hardware performance counter (STATGROUP_HWCPipe) to obtain specific hardware (e.g., L1 cache) behavior. Specifically, `DECLARE_STATS_GROUP` declares a performance statistics group named "HWCPipe," categorized under the "Advanced" statistics category (STATCAT_Advanced). This statistics group organizes related performance metrics together for easier classification and management. `DECLARE_FLOAT_COUNTER_STAT` declares a floating-point performance counter. Two counters are declared here:

[0080] 1. STAT_L1DataCacheAccess: A statistic named "L1 Data Cache Access" that indicates the number of L1Cache hits.

[0081] 2. STAT_L1DataCacheRefill: A statistic named "L1 Data Cache Refill" that represents the number of L1Cache misses.

[0082] Both counters are registered to the previously declared STATGROUP_HWCPipe statistics group to record performance data related to hardware pipelines (such as L1 cache).

[0083] Furthermore, based on the above hardware data acquisition configuration, whenever the hardware performance counter collects a sample, a performance index (stat_index) is obtained according to the classification of the counting group. Specific group data settings are then performed based on the performance index (stat_index). For example, if an L1_Data_Cache_Access value is received, the corresponding value will be assigned and saved in L1_Data_Cache_Access; similarly, if an L1_Data_Cache_Refill value is received, the corresponding value will be assigned and saved in L1_Data_Cache_Refill. An example of performance statistics implementation code in a game engine development environment is as follows:

[0084] switch(stat_index)

[0085] case StatIndex::Ll_Data_Cache_Access:

[0086] SET_FLOAT_STAT(STAT_L1DataCacheAccess,value);

[0087] break;

[0088] case StatIndex::L1_Data_Cache Refill:

[0089] SET_FLOAT_STAT(STAT_L1DataCacheRefill,value);

[0090] break;

[0091] Here, `stat_index` is an enumeration variable representing different performance metric indices. It is assumed that the `StatIndex` enumeration defines two members: `L1_Data_Cache_Access` and `L1_Data_Cache_Refill`, corresponding to the performance statistics of L1 Cache access count and L1 Cache miss count, respectively.

[0092] In a "switch" statement:

[0093] 1. When `stat_index` equals `StatIndex::L1_Data_Cache_Access`, the `SET_FLOAT_STAT` function is called, assigning the `value` parameter to a floating-point performance counter named `STAT_L1DataCacheAccess`. This means that when the L1 data cache is accessed, the corresponding access count will be recorded.

[0094] 2. Similarly, when stat_index equals StatIndex::L1_Data_Cache_Refill, the value is assigned to the STAT_L1DataCacheRefill performance counter to record the number of times the L1 data cache is filled (i.e., data is read from the next level cache or memory after a cache miss), which can be used to represent the number of L1 cache misses.

[0095] The SET_FLOAT_STAT function is an interface provided by the game engine for updating performance statistics. In this way, developers can obtain and analyze the performance data of the game in real time, thereby optimizing and debugging.

[0096] Continue to refer to Figure 4 In step S320-3, the target hardware metrics are obtained cyclically. Specifically, based on the above configuration, the final underlying hardware CacheMiss data is transferred from the driver layer to the engine layer. For example, the engine's implementation code for cyclically obtaining data is as follows:

[0097] nt32 AndroidMain(struct android_app*state)

[0098] / / ...

[0099] hwcpipe::GAndroidEnab1eHWCPipe=FAndroidMisc::IsEnab1eHWCPipe();

[0100] Tick ​​until done

[0101] while(!GIsRequestingExit)

[0102] FAndroidStats::UpdateAndroidStats();

[0103] FAppEventManager::GetInstance()->Tick();

[0104] / / hwcpipe tick

[0105] if(hwcpipe::GAndroidEnab1eHWCPipe)

[0106] hwcpipe::Stats::GetInstance()->Tick(FApp::GetDeltaTime());

[0107] if(!FAppEventManager::GetInstance()->IsGamePaused())

[0108] GEngineLoop.Tick();

[0109] else

[0110] / / use less CPU when paused

[0111] FP1atformProcess::S1eep(0.10f);

[0112] Add a check to the core function AndroidMain of the engine to determine whether hardware data acquisition is enabled. Specifically, the function FAndroidMisc::IsEnableHWCPipe() can be used to determine whether the current hardware performance counter module is enabled.

[0113] The `while` loop continuously acquires hardware data, with the `GisRequestingExit` condition being a flag indicating whether hardware data acquisition is needed. Specifically, a value of `False` indicates continuous hardware data acquisition, while a value of `True` indicates that data acquisition is complete and the loop can exit. During acquisition, the `hwcpipe::GAndroidEnableHWCPipe` flag is used to determine if the hardware performance counter is enabled. A value of `True` indicates the hardware performance counter is enabled and data acquisition is possible, while a value of `False` indicates the hardware performance counter is disabled and data acquisition is not possible.

[0114] The measurement sample (MeasureSample) is obtained through the collection function `hwcpipe::Stats::GetInstance()->Tick`. The parameter passed to the collection function is `FApp::GetDeltaTime()`. The `GetDeltaTime` function is mainly used to determine the collection timestamp. Specifically, the collection timestamp is the time when the target scenario occurs. For example, the difference between the current time and the start time of the application under test is used to determine the collection timestamp. The `Tick` function retrieves the registered data from the counting group at the collection time point to obtain the measurement sample package. For example, the measurement sample package `MeasureSample` is retrieved from `HWCPipe`. Since `L1DataCacheAccess` and `L1DataCacheRefill` are registered in the counting module, the following parsing processing can be performed on the two types of data in this measurement sample package: `MeasureSample.find(L1DataCacheAccess).get`. <float>(),MeasureSample.find(L1DataCacheRefill).get <float>This allows us to obtain the target hardware metrics L1DataCacheAccess and L1DataCacheRefill values ​​related to the cache. Next, these two values ​​are assigned to the statistical categories STAT_L1DataCacheAccess and STAT_L1DataCacheRefill mentioned above, thus completing the final transfer of underlying hardware data from the driver layer to the final engine layer.

[0115] Based on the specific implementation of step S330, the target hardware metrics cached in the test device under the target scenario can be obtained, such as cache miss data and cache hit data. (Exemplary reference...) Figure 5 Currently, multi-core CPUs include processors A78 and A55. The above embodiments of this application can obtain cache hit and miss data for each of the two processors. Specifically, Access represents the total amount of reads and writes from the L1 cache by the current CPU, and Refill represents the amount of data that the current CPU cannot read from L1, triggering a CacheMiss. Therefore, the embodiments of this application can accurately obtain the measurement values ​​of hardware metrics (such as CacheMiss) during game operation.

[0116] Since the aforementioned target hardware metrics are time-related, this embodiment can further identify the functions that cause the target hardware metrics to consume too much time, thus obtaining the optimization points. For example, if the target hardware metric is the cache miss rate, then the functions causing a high cache miss rate are further identified as optimization points. By optimizing these functions, the cache miss rate can be reduced, ultimately optimizing application time consumption. For instance, this technical solution can accurately obtain the CacheMiss value of the target scenario, and further, it can determine whether a CacheMiss occurred during game code execution. When a CacheMiss occurs, this embodiment can also specifically pinpoint which functions' execution leads to this CacheMiss.

[0117] Continue to refer to Figure 3 In S340, if the target hardware indicator does not meet the second preset condition, the function to be optimized is determined from the target function set, wherein the target function set includes the function corresponding to the target scenario.

[0118] In an exemplary embodiment, the target hardware metric can be the number of cache misses. For example, as described above, L1_Data_Cache_Refill records the number of times the L1 data cache is filled, i.e., the number of L1 cache misses. In this case, the second preset condition can be that the number of cache misses is not greater than the first preset threshold. For example, if the first preset threshold is 10000, and the number of cache misses in test device 22 during scenario A is 50000, since the number of cache misses in test device 22 during scenario A is less than the first preset threshold, it indicates that the target hardware metric meets the second preset condition in scenario A. Conversely, if the number of cache misses in test device 22 during scenario B is 110000, since the number of cache misses in test device 22 during scenario B is greater than the first preset threshold, it indicates that the target hardware metric does not meet the second preset condition in scenario B.

[0119] In an exemplary embodiment, the aforementioned target hardware metric can be the number of cache misses and the number of cache hits. For example, as described above, L1_Data_Cache_Refill records the number of times the L1 data cache is filled, i.e., the number of L1 cache misses; L1_Data_Cache_Access identifies the number of L1 cache hits. In this case, the aforementioned second preset condition can be that the number of cache misses is not greater than the first preset threshold, or that the ratio of the number of cache misses to the number of cache hits is not greater than the second preset threshold. For example, if the second preset threshold is 20%, and the number of cache misses in test device 22 is 500 and the number of cache hits is 5000 when running scenario A, since the ratio in scenario A is 10% and less than the second preset threshold, it indicates that the target hardware metric in scenario A meets the aforementioned second preset condition.

[0120] In an exemplary embodiment, the aforementioned target hardware metric can be the cache miss rate. The cache miss rate can be expressed as: number of cache misses / (number of cache misses + number of cache hits). For example, as described above, L1_Data_Cache_Refill records the number of times the L1 data cache is filled, i.e., the number of L1 cache misses; L1_Data_Cache_Access identifies the number of L1 cache hits. In this case, the aforementioned second preset condition can be that the cache miss rate is not greater than the fourth preset threshold. For example, if the fourth preset threshold is 10%, and the cache miss rate in test device 22 is 5% when running scenario A, since the cache miss rate of 5% in scenario A is less than the fourth preset threshold, it indicates that the target hardware metric in scenario A meets the aforementioned second preset condition.

[0121] In an exemplary embodiment, the aforementioned target hardware metric can be the cache hit rate. The cache hit rate can be expressed as: number of cache hits / (number of cache misses + number of cache hits). For example, as described above, L1_Data_Cache_Refill records the number of times the L1 data cache is filled, i.e., the number of L1 cache misses; L1_Data_Cache_Access identifies the number of L1 cache hits. In this case, the aforementioned second preset condition can be that the cache miss rate is not less than the fifth preset threshold. For example, if the fifth preset threshold is 90%, and the cache hit rate in test device 22 is 85% when running scenario B, since the cache hit rate in scenario A is less than the fifth preset threshold, it indicates that the target hardware metric in scenario A does not meet the aforementioned second preset condition.

[0122] In an exemplary embodiment, if the target hardware metric does not meet the corresponding second preset condition in the target scenario, it indicates that there are functions to be optimized in the function set called in the current scenario. For example, if the cache miss rate in the target hardware metric is the cache miss rate in the target scenario, and the number of cache misses in target scenario C exceeds the threshold (5%), it indicates that there are functions to be optimized in the functions called in target scenario C. The cache miss rate in this scenario can be reduced by optimizing the relevant functions.

[0123] In an exemplary embodiment, all functions called in the target scenario can be denoted as the target function set. Further, based on the cache miss percentage of each function in the target function set, the aforementioned function to be optimized is determined within the target function set. Here, the cache miss percentage is the ratio between the number of cache misses of a function and the total number of cache misses in the current target scenario. For example, the target function set D called in target scenario D includes functions D1, D2, and D3, and according to the embodiment provided in step S330, the number of cache misses of the test device 22 when running target scenario D is determined to be X; then the cache miss percentage of function D1 is the ratio of the number of misses d1 of function D1 to X. Similarly, the cache miss percentage of function D2 is the ratio of the number of misses d2 of function D2 to X, and the cache miss percentage of function D3 is the ratio of the number of misses d3 of function D3 to X. However, the number of misses corresponding to a single function is a value that cannot be directly obtained at the moment; that is, the number of misses d1, d2, and d3 mentioned above cannot be directly obtained.

[0124] As mentioned earlier, there is a correlation between some hardware metrics of caching and CPU utilization (e.g., a high cache miss rate is likely to be accompanied by a high CPU utilization rate). Since the CPU utilization rate corresponding to a function is directly obtained, this embodiment uses the CPU utilization rate corresponding to the function as the cache miss rate of the aforementioned function. It is evident that even if a high cache miss rate is known in the related technologies, it is impossible to specifically analyze the cause of the high cache miss rate. However, this embodiment can achieve this by... Figure 6 The method shown allows for precise identification of the functions causing high CacheMiss. For example, Figure 6 The flowchart illustrating the method for determining the function to be optimized provided in this application embodiment can be used as a specific implementation of S340.

[0125] refer to Figure 6 In step S340-1, if the acquired target hardware indicators do not meet the second preset condition, the CPU utilization rate of each function in the target function set is acquired.

[0126] In an exemplary embodiment, the game engine's built-in performance analysis tool (Profiler) can be used to perform function-level CPU time consumption analysis. The Profiler can record the number of function calls in each frame, the duration of each call, and the total CPU time usage. By statistically analyzing this data, it is possible to determine which functions consume the most CPU resources during runtime, thus obtaining the function-level CPU utilization. For non-game engine environments, various performance analysis libraries (such as gprof for Linux, VTune for Windows, or the cross-platform high-performance analysis toolkit gperftools) can be used to obtain function-level CPU time statistics, thereby determining the function-level CPU utilization.

[0127] Exemplary Reference Figure 7 The figure shows the CPU utilization rate of the function during its execution. In this embodiment, the CPU utilization rate at the function level can be used as the miss rate of the function. For example, refer to... Figure 7 The current CPU utilization (cache miss percentage) of FileSize is 8.91%. Further, since the total number of cache misses in this target scenario can be determined according to the above step S330 embodiment, for example, 730494, the cache miss count for each function is determined based on the above miss percentage and the above total number of cache misses. For example, the current cache miss count for FileSize is 8.91% × 730494 = 65087.

[0128] Continue to refer to Figure 6 In step S340-2, the function to be optimized is determined from the set of target functions based on the CPU utilization rate of each function.

[0129] The cache miss percentage reflects the contribution of the current set of target functions to the total number of cache misses. Specifically, the higher the cache miss percentage of a function in the target function set, the greater its contribution to the number of cache misses in the target scenario; conversely, the lower the cache miss percentage of a function in the target function set, the smaller its contribution to the number of cache misses in the target scenario. Therefore, in this embodiment, the function to be optimized is determined based on the CPU utilization (cache miss percentage) of each function.

[0130] For example, the function to be optimized can be a function whose CPU utilization rate is greater than a third preset threshold, such as a function whose CPU utilization rate (cache miss rate) is greater than 50%. The third preset threshold can be a fixed value or a value that is dynamically adjusted according to actual needs; this embodiment does not limit this.

[0131] For example, the N functions with the highest CPU utilization in the target function set can be selected as the functions to be optimized, where N is a positive integer. For instance, if the target function set D called in the target scenario D contains functions D1, D2, and D3, and the cache miss rate of function D1 is 60%, the cache miss rate of function D2 is 30%, and the cache miss rate of function D3 is 10%, then in this embodiment, the two functions with the highest CPU utilization (cache miss rate) can be selected as the functions to be optimized.

[0132] In an exemplary embodiment, the call sequences of functions in the target function set can also be symbolically parsed to obtain readable function information. During performance analysis, based on the readable function information obtained after symbolic parsing, relevant personnel can clearly see which function occupies most of the execution time, thereby quickly identifying performance bottlenecks.

[0133] Figure 8 This is a flowchart illustrating the symbolic parsing method P800 for function call sequences provided in this application embodiment. The following embodiments use any one function (denoted as the target function) from the aforementioned target function set as an example to describe the symbolic parsing process for function call sequences.

[0134] refer to Figure 8 In step S81, the function address is determined.

[0135] During program execution, each function call occupies a specific address in memory. This address is the actual location the CPU jumps to when the function is executed. The operating system and compiler allocate space for each function and can record the address and other context information of the current function in some way (such as through registers or stack frames) during the call. For example, when using the performance analysis tool (Profiler) built into the game engine to perform function-level CPU time consumption analysis, the memory address of the target function can be obtained.

[0136] refer to Figure 8 Method P800 further includes step S82: obtaining the starting position of the stack. Specifically, computing device 20 obtains the starting position of the stack frame where the objective function is located.

[0137] A stack frame is space allocated on the stack during a function call, used to store information such as function parameters, local variables, and return address. By obtaining the starting address of the stack frame, we can further analyze the function's local variables, call history, and so on.

[0138] For example, a built-in function such as `__builtin_frame_address` can return the address of the current function's stack frame in the call stack. In this embodiment, the starting position of the target function's stack frame can be determined by the return value of the first function (e.g., the engine's built-in function `__builtin_frame_address`), where the returned value of the built-in function `__builtin_frame_address` is determined based on the target function's address.

[0139] refer to Figure 8 Method P800 further includes step S83: obtaining the end position of the stack. Specifically, computing device 20 obtains the end position of the stack frame containing the aforementioned objective function.

[0140] For example, the computing device 20 first obtains the stack frame attributes of the thread containing the target function through a second function (e.g., pthread_attr_getstack), where the stack frame attributes include the stack frame range of the thread. It is important to note that pthread_attr_getstack returns the range information of the entire thread stack, not the end address of the target function call stack frame. Therefore, in this embodiment, other information, such as stack frame layout information automatically maintained by the compiler, is needed to analyze the size range of the stack frame containing the target function. Then, the computing device 20 determines the end position of the stack frame containing the target function based on the start position and the size range of the stack frame containing the target function. For example, the end address of the stack frame containing the target function can be indirectly obtained by adding the size range of the stack frame to the start address of the stack frame containing the target function.

[0141] refer to Figure 8 Method P800 further includes step S84: determining the function call sequence. Specifically, computing device 20 determines the call sequence of the target function.

[0142] When a function calls itself or other functions, the resulting multi-level nested calls form a recursive call chain. During a function call, the system maintains a call stack. Whenever a function call occurs, the address of the called function is pushed onto the stack so that after the function finishes execution, it can correctly return to the calling function to continue execution.

[0143] Figure 9 This is a schematic diagram of the stack frame structure in memory provided in an embodiment of this application. (Reference) Figure 9 In 32-bit or 64-bit computer systems, stack frames typically grow from high addresses to low addresses. This means that for a downward-growing stack, the stack pointer (SP) decreases each time data is pushed onto the stack. During a function call, the return address (i.e., the address of the next instruction to be executed after the function call) is pushed onto the stack, along with local variables, temporary variables, and other function parameters.

[0144] For example, suppose we have the following simple function call sequence on a 32-bit machine:

[0145]

[0146]

[0147] After calling main(), funcA() is called, and then funcA() calls funcB(). The stack frame structure at this point can be as follows:

[0148] +------------------+

[0149] |main's ret addr|

[0150] +------------------+

[0151] |funcA()'s frame|

[0152] |localVar|

[0153] |funcB()'s addr|

[0154] +------------------+

[0155] |funcB()'s frame|

[0156] |anotherVar|

[0157] |funcB's ret addr|

[0158] +------------------+

[0159] In the stack, the return address of main() is first pushed onto the top of the stack. Then, the stack frame for funcA() is created, containing the local variable localVar and the address of funcB(). Next, funcB() is called, and its stack frame is located below the stack frame of funcA(), containing the local variable anotherVar and the return address of funcB().

[0160] In this embodiment, obtaining the complete function call sequence by traversing the stack frames requires starting from the current top of the stack (such as the stack frame of funcB() above) and continuously retrieving data in the direction of decreasing address (each 4 or 8 bytes represents an address or data). In this way, the return address of funcB(), the stack frame data of funcA() (containing the address of funcB()), and finally the return address of main() can be obtained sequentially from the bottom of the stack upwards. By parsing these addresses, the call sequence for funcB() can be reconstructed: main()->funcA()->funcB().

[0161] refer to Figure 8 Method P800 also includes step S85: summarizing the call sequence.

[0162] For example, after determining the call sequence of each function in the target function set, multiple call sequences can be aggregated to further perform symbolic parsing on the above multiple call sequences, so that each call sequence is readable.

[0163] The call sequence is represented by the address values ​​of the relevant functions. Since many function call sequences have repeated function addresses, this application embodiment can also perform the symbolic resolution process by setting a dictionary, thereby greatly improving the resolution efficiency by reusing the resolved results.

[0164] refer to Figure 8 In step S86, an address dictionary is established. Specifically, the address dictionary includes the correspondence between function addresses and function names.

[0165] For example, the `dladdr` function can be used to reverse-engineer a function's address and find its name and associated dynamic link library information. The `dladdr` function is a dynamic link library (DLL) function in Unix-like systems (such as Linux and macOS) used to retrieve information about the DLL containing a given function. The `dladdr` function returns a `Dl_info` structure, which contains the function's name, the base address of its DLL, its symbol name, and other information. An example of a `Dl_info` structure is as follows:

[0166] struct{

[0167] const char* dli fname;

[0168] void*dli fbase;

[0169] const char* dli sname;

[0170] void*dli_saddr;

[0171] size t dli size; / *ELF only* /

[0172] int dli_bind; / *ELF only* /

[0173] int dli_type;

[0174] };

[0175] The meanings of each field in the above structure are as follows:

[0176] dli_fname: A character pointer to the filename of the dynamic link library containing the function.

[0177] dli_fbase: A pointer that points to the base address of the dynamic link library in memory.

[0178] dli_sname: A character pointer that points to the symbolic name of a function, i.e., the function name.

[0179] dli_saddr: A pointer that points to the starting address of the function.

[0180] dli_size: (Available only in ELF format dynamic link libraries) Indicates the size of the symbol, i.e. the length of the function.

[0181] dli_bind: (Available only in ELF format dynamic link libraries) indicates the symbol binding type, such as global, weak global, local, etc.

[0182] dli_type: Indicates the type of the search result, such as search success, search failure, or an address of an unknown type was found.

[0183] For example, the `dladdr` function can determine the function name A corresponding to the function address `a`. Similarly, an address dictionary can be constructed by combining multiple function addresses and their corresponding function names. Therefore, when performing symbolic parsing of the call sequence of the target function, this address dictionary can be consulted, allowing for efficient determination of the function name corresponding to a function address by directly utilizing the mapping relationships contained within the address dictionary.

[0184] Continue to refer to Figure 8 In step S87, the name of the function to be called is obtained.

[0185] For example, based on the address dictionary mentioned above, symbolic parsing is performed on the call sequence of the target function to replace the function address in the call sequence with the corresponding function name.

[0186] For example, for a function address in the call sequence, if the current address dictionary does not yet contain the function name corresponding to that function address, the corresponding function name can be determined based on the dladdr function, and then the function address and its corresponding function name can be updated to the address dictionary after determination.

[0187] Through the embodiments of this application, the complete stack of the function that caused the CacheMiss can be obtained, and a readable function call sequence can be obtained after symbolic parsing.

[0188] In this embodiment, target hardware metrics cached by the test device in a target scenario are obtained, such as cache misses. When the cache misses exceed the limit, functions that significantly contribute to the excessive cache misses are identified as functions to be optimized. Therefore, this embodiment provides a scheme for determining the function to be optimized based on cached hardware metrics, which helps to increase the richness of optimization points and thus improves the optimization efficiency of the application under test.

[0189] It is understood that, in addition to determining the function to be optimized based on the hardware indicators of the cache, the embodiments of this application can also determine the function to be optimized by recording using the Stat function in related technologies, thereby more comprehensively determining the points to be optimized.

[0190] Continue to refer to Figure 3 Method P300 further includes step S350: executing an optimization strategy for the function to be optimized in order to optimize the performance of the application under test.

[0191] In related technologies, recording using the Stat function identifies functions with excessively long execution times as those to be optimized. While this pinpoints the time-consuming functions, the solutions provided by these technologies do not clearly explain the reasons for the excessive execution time. Therefore, for the functions identified through these technologies, targeted optimization methods cannot be provided. Generally, lossy optimization methods are used to reduce the resulting time consumption, such as reducing the frequency of use of the functions to be optimized.

[0192] In this embodiment, since the specific reasons for the excessively long execution time of the optimization point can be clearly identified, such as the high cache miss rate of function x leading to long execution time, this embodiment can provide targeted optimization methods for function x. For example, when the cache miss rate is too high, the following strategies can be used to optimize the cache miss rate: 1. Increasing cache capacity: If the cache space is insufficient, increasing the cache size can accommodate more data items, thereby improving the hit rate of the function to be optimized. 2. Preloading or preheating the cache: Actively loading frequently accessed data into the cache before a request arrives, or loading hot data during application startup. 3. Optimizing data structure and access patterns: Specifically, this can include cache locality optimization and cache affinity; cache locality optimization refers to utilizing the principle of locality of access, such as storing related data blocks together for arrays or continuous data structures to facilitate cache line filling; cache affinity refers to optimizing code organization and execution order to ensure consistency and continuity of related data in the cache, thereby reducing the possibility of cache conflicts and misses. 4. Sharding and partitioning caching methods; such as dividing data according to certain logical or physical characteristics and distributing it across multiple cache instances to avoid a decrease in hit rate caused by an excessively large single cache instance. It is understood that the optimization methods are not limited to the above methods, and this application's embodiments do not limit them.

[0193] As can be seen, compared with the lossy optimization method used in related technologies, the optimization method provided in this application is highly targeted and can effectively avoid the impact on the user experience.

[0194] In the application performance optimization scheme provided in this application embodiment, after determining the target scenario where the CPU utilization rate of the application under test meets a first preset condition (e.g., high CPU utilization rate), the target hardware indicators cached under the target scenario are obtained, wherein the target hardware indicators are time-related indicators. Further, if the target hardware indicators do not meet a second preset condition, the function to be optimized is determined from the target function set, wherein the target function set consists of all functions corresponding to the target scenario. The performance of the application under test is then optimized based on the function to be optimized. Related technologies do not provide a scheme for determining the function to be optimized based on cached hardware indicators. This application embodiment can overcome the above-mentioned deficiencies in related technologies by obtaining the target hardware indicators cached under the target scenario and determining the function to be optimized when the target hardware indicators do not meet the preset conditions. This helps to improve the richness of the optimization points, thereby providing more optimization space for the performance optimization of the application under test, and thus helping to improve the optimization efficiency of the application under test. Meanwhile, since the embodiments of this application can clearly identify the specific reasons for the excessive time consumption of the optimization point (such as a high cache miss rate), targeted optimization methods are provided (for example, the optimization methods used when the cache miss rate is too high may include resource reset or optimized resource reading, etc.). Compared with the lossy optimization methods used in related technologies, the optimization scheme provided by the embodiments of this application can effectively avoid the impact on the user experience.

[0195] The above text combined Figures 1 to 9 The method embodiments of this application are described in detail below, in conjunction with... Figure 10 The following describes in detail the device embodiments of this application.

[0196] Figure 10 A schematic diagram of the structure of the performance optimization device 1000 provided in this application embodiment. (See reference) Figure 10 The performance optimization device 1000 for this application includes: a first acquisition module 1010, a first determination module 1020, a second acquisition module 1030, a second determination module 1040, and an optimization module 1050; wherein, the first acquisition module 1010 is used to acquire the CPU utilization rate of the central processing unit of the device under test during the operation of the application under test on the test device; the first determination module 1020 is used to determine the target scenario of the application under test based on the CPU utilization rate, wherein the CPU utilization rate of the application under test in the target scenario meets a first preset condition; the second acquisition module 1030 is used to acquire the target hardware indicators cached in the test device in the target scenario, wherein the target hardware indicators are time-related indicators; the second determination module 1040 is used to determine the function to be optimized from the set of target functions when the target hardware indicators do not meet the second preset condition, wherein the set of target functions includes the function corresponding to the target scenario; and the optimization module 1050 is used to execute an optimization strategy for the function to be optimized to optimize the performance of the application under test.

[0197] In an exemplary embodiment, based on the above scheme, the second acquisition module 1030 includes a setting unit and a capture unit; wherein, the setting unit is used to: acquire the target hardware indicators cached in the test device through a hardware performance counter; and the capture unit is used to: capture the information acquired by the hardware performance counter based on the timestamp of the target scenario, and obtain the target hardware indicators cached in the test device under the target scenario.

[0198] In an exemplary embodiment, based on the above scheme, the performance optimization device 1000 further includes a loading module; wherein the loading module is used to load the source file of the hardware performance counter into the startup module of the engine of the application under test in the form of a counting module before the crawling unit crawls the information obtained by the hardware performance counter based on the timestamp of the target scene, so as to load the counting module in the pre-initialization stage of the engine startup process.

[0199] In an exemplary embodiment, based on the above scheme, the performance optimization device 1000 of the above application further includes: a registration module; wherein. The registration module is used to: before the above-mentioned war zone unit captures the information obtained by the above-mentioned hardware performance counter based on the timestamp of the above-mentioned target scenario, add a counting group for the above-mentioned hardware performance counter in the performance statistics system of the engine of the application under test, so as to classify and manage the target hardware indicators obtained by the above-mentioned hardware performance counter; and register the statistical category used to store the above-mentioned target hardware indicators to the above-mentioned counting group, wherein the above-mentioned target hardware indicators include: cache miss data, or, cache miss data and cache hit data.

[0200] In an exemplary embodiment, based on the above scheme, the above-mentioned capture unit is specifically used to: capture the registered data in the above-mentioned counting group to obtain a measurement sample package based on the timestamp of the above-mentioned target scenario, so as to obtain the target hardware indicators cached in the above-mentioned target scenario; wherein, the timestamp of the above-mentioned target scenario is the difference between the current time point and the startup time point of the above-mentioned application under test.

[0201] In an exemplary embodiment, based on the above scheme, the target hardware metric includes: the number of cache misses; the second determining module 1030 is specifically used to: when the number of cache misses is greater than a first preset threshold, determine the function to be optimized in the target function set according to the cache miss ratio of each function in the target function set; the target hardware metric includes: the number of cache misses and the number of cache hits; the second determining module 1030 is specifically used to: when the number of cache misses is greater than a first preset threshold, or when the ratio of the number of cache misses to the number of cache hits is greater than a second preset threshold, determine the function to be optimized in the target function set according to the cache miss ratio of each function in the target function set; wherein, the cache miss ratio is the ratio between the number of cache misses of the function and the total number of cache misses in the target scenario.

[0202] In an exemplary embodiment, based on the above scheme, the second determining module 1030 is specifically used to: obtain the CPU utilization rate of each function in the target function set when the target hardware indicators do not meet the second preset condition; and determine the function to be optimized in the target function set according to the CPU utilization rate of each function; wherein the function to be optimized is a function whose CPU utilization rate is greater than a third preset threshold, or the N functions with the largest CPU utilization rate in the target function set are the functions to be optimized, where N is a positive integer.

[0203] In an exemplary embodiment, based on the above scheme, the performance optimization device 1000 for the above application further includes a parsing module; wherein the parsing module includes an acquisition unit, a determination unit, and a parsing unit; wherein the acquisition unit is used to: acquire the start position of the stack frame containing the target function in the target function set and acquire the end position of the stack frame containing the target function before the optimization module 1050 executes the optimization strategy for the function to be optimized to optimize the performance of the application under test, wherein the target function is any function in the target function set; the determination unit is used to: determine the call sequence of the target function based on the start and end positions of the stack frame; and the parsing unit is used to: perform symbolic parsing on the call sequence to obtain readable function information about the target function.

[0204] In an exemplary embodiment, based on the above scheme, the acquisition unit is specifically used to: determine the function address of the target function; and determine the starting position of the stack frame where the target function is located by the return value of the first function, wherein the first function is the one whose return value is determined based on the function address of the target function.

[0205] In an exemplary embodiment, based on the above scheme, the acquisition unit is further configured to: acquire the stack frame attributes of the thread where the target function is located through the second function, wherein the stack frame attributes of the thread include the stack frame range of the thread; and determine the end position of the stack frame where the target function is located based on the start position of the stack frame where the target function is located and the stack frame range of the thread.

[0206] In an exemplary embodiment, based on the above scheme, the parsing unit is specifically used to: set an address dictionary, wherein the address dictionary includes the correspondence between function addresses and function names; and, according to the address dictionary, perform symbolic parsing on the call sequence to replace the function addresses in the call sequence with the corresponding function names.

[0207] In an exemplary embodiment, based on the above scheme, the optimization module 1050 is specifically used to: perform at least one of the following optimization strategies on the function to be optimized: resource reset and optimized resource reading, so as to optimize the performance of the application under test.

[0208] It should be understood that the application performance optimization apparatus embodiments and application performance optimization method embodiments can correspond to each other, and similar descriptions can be found in the method embodiments. To avoid repetition, further details are omitted here. Specifically, Figure 10 The performance optimization apparatus shown can execute embodiments of the performance optimization method of the above-described application, and the aforementioned and other operations and / or functions of each module in the apparatus are respectively for implementing embodiments of the performance optimization method of the application, which will not be described in detail here for the sake of brevity.

[0209] The apparatus of the method embodiments of this application has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application can be completed by integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the method disclosed in the embodiments of this application can be directly embodied as being executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0210] Figure 11 This is a schematic block diagram of the electronic device 1100 provided in the embodiments of this application. Figure 11 The electronic device 1100 can be used to perform the performance optimization methods described above. For example... Figure 11 As shown, the electronic device 1100 may include:

[0211] The system includes a memory 1110 and a processor 1120. The memory 1110 stores a computer program 1130 and transfers the program code 1130 to the processor 1120. In other words, the processor 1120 can call and run the computer program 1130 from the memory 1110 to implement the methods in the embodiments of this application.

[0212] For example, the processor 1120 can be used to execute the steps in the above method according to the instructions in the computer program 1130.

[0213] In some embodiments of this application, the processor 1120 may include, but is not limited to:

[0214] General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0215] In some embodiments of this application, the memory 1110 includes, but is not limited to:

[0216] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0217] In some embodiments of this application, the computer program 1130 may be divided into one or more modules, which are stored in the memory 1110 and executed by the processor 1120 to perform the performance optimization method of the application provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 1130 in the electronic device.

[0218] like Figure 11 As shown, the electronic device 1100 may further include:

[0219] Transceiver 1140, which can be connected to processor 1120 or memory 1110.

[0220] The processor 1120 can control the transceiver 1140 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 1140 may include a transmitter and a receiver. The transceiver 1140 may further include antennas, and the number of antennas may be one or more.

[0221] It should be understood that the various components in the electronic device 1100 are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0222] According to one aspect of this application, a computer storage medium is provided that stores a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, embodiments of this application also provide a computer program product containing instructions that, when executed by a computer, cause the computer to perform a performance optimization method for the application of the above-described method embodiments.

[0223] According to another aspect of this application, a computer program product or computer program is provided, comprising 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 performance optimization method of the application described in the above-described method embodiments.

[0224] In other words, when implemented using software, it can be implemented wholly or partially in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0225] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0226] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0227] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0228] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / float> < / float>

Claims

1. A performance optimization method for an application, characterized in that, The method includes: During the process of running the application under test on the test equipment, the CPU utilization rate of the central processing unit of the test equipment is obtained; The target scenario of the application under test is determined based on the CPU utilization rate, wherein the CPU utilization rate of the application under test in the target scenario meets a first preset condition. Obtain the target hardware metrics cached in the test device under the target scenario, wherein the target hardware metrics are time-related metrics; If the target hardware indicator does not meet the second preset condition, the function to be optimized is determined from the target function set, wherein the target function set includes the function corresponding to the target scenario; Execute optimization strategies for the function to be optimized to improve the performance of the application under test.

2. The method according to claim 1, characterized in that, The step of obtaining the target hardware metrics cached in the test device under the target scenario includes: The target hardware metrics cached in the test device are obtained using hardware performance counters. Based on the timestamp of the target scenario, information obtained from the hardware performance counter is captured to obtain the target hardware metrics cached in the test device under the target scenario.

3. The method according to claim 2, characterized in that, Before retrieving the information obtained from the hardware performance counter based on the timestamp of the target scene, the method further includes: The source file of the hardware performance counter is loaded into the startup module of the engine of the application under test as a counting module, so as to load the counting module in the pre-initialization phase of the engine startup process.

4. The method according to claim 2, characterized in that, Before retrieving the information obtained from the hardware performance counter based on the timestamp of the target scene, the method further includes: In the performance statistics system of the engine of the application under test, add a counting group for the hardware performance counter to classify and manage the target hardware indicators obtained by the hardware performance counter. The statistical categories used to store the target hardware metrics are registered to the counting groups, wherein the target hardware metrics include: cache miss data, or cache miss data and cache hit data.

5. The method according to claim 4, characterized in that, The step of capturing information from the hardware performance counter based on the timestamp of the target scenario to obtain the target hardware metrics cached in the test device under the target scenario includes: Based on the timestamp of the target scenario, the registered data in the counting group is captured to obtain the measurement sample package, so as to obtain the target hardware indicators cached in the target scenario. The timestamp of the target scene is the difference between the current time and the start time of the application under test.

6. The method according to any one of claims 1 to 5, characterized in that, The target hardware metric includes: the number of cache misses; when the target hardware metric does not meet the second preset condition, determining the function to be optimized from the set of objective functions includes: If the number of cache misses exceeds a first preset threshold, the function to be optimized is determined in the target function set based on the cache miss percentage of each function in the target function set. The target hardware metrics include: cache misses and cache hits; when the target hardware metrics do not meet the second preset condition, the function to be optimized is determined from the set of objective functions, including: If the number of cache misses is greater than a first preset threshold, or if the ratio of the number of cache misses to the number of cache hits is greater than a second preset threshold, the function to be optimized is determined in the target function set based on the cache miss percentage of each function in the target function set. The cache miss rate is the ratio between the number of cache misses of the function and the total number of cache misses in the target scenario.

7. The method according to claim 6, characterized in that, The step of determining the function to be optimized based on the cache miss rate of each function in the target function set includes: If the target hardware metric does not meet the second preset condition, obtain the CPU utilization rate of each function in the target function set; Based on the CPU utilization of each function, the functions to be optimized are determined from the set of target functions; Wherein, the function to be optimized is a function whose CPU utilization rate is greater than a third preset threshold, or the N functions with the highest CPU utilization rate in the target function set are the functions to be optimized, where N is a positive integer.

8. The method according to any one of claims 1 to 5, characterized in that, Before executing the optimization strategy for the function to be optimized to improve the performance of the application under test, the method further includes: Obtain the starting position of the stack frame containing the target function in the target function set, and obtain the ending position of the stack frame containing the target function, wherein the target function is any function in the target function set; Based on the start and end positions of the stack frames, the call sequence of the target function is determined; The call sequence is symbolically parsed to obtain readable function information about the target function.

9. The method according to claim 8, characterized in that, Obtaining the starting position of the stack frame containing the target function in the target function set includes: Determine the function address of the objective function; The starting position of the stack frame containing the target function is determined by the return value of the first function, wherein the return value of the first function is determined based on the function address of the target function.

10. The method according to claim 8, characterized in that, Obtaining the end position of the stack frame containing the target function includes: The stack frame attributes of the thread containing the target function are obtained through the second function, wherein the stack frame attributes of the thread include the stack frame range of the thread; Based on the starting position of the stack frame containing the target function and the stack frame range of the thread, the ending position of the stack frame containing the target function is determined.

11. The method according to claim 8, characterized in that, The symbolic parsing of the call sequence includes: Set an address dictionary, wherein the address dictionary includes the correspondence between function addresses and function names; Based on the address dictionary, symbolic parsing is performed on the call sequence to replace the function addresses in the call sequence with the corresponding function names.

12. The method according to any one of claims 1 to 5, characterized in that, The execution of the optimization strategy for the function to be optimized to improve the performance of the application under test includes: Perform at least one of the following optimization strategies on the function to be optimized: resource reset and optimized resource reading, in order to optimize the performance of the application under test.

13. A performance optimization device for an application, characterized in that, The device includes: The first acquisition module is used to acquire the CPU utilization rate of the central processing unit of the device under test during the process of running the application under test on the test device. The first determining module is used to determine the target scenario of the application under test based on the CPU utilization rate, wherein the CPU utilization rate of the application under test in the target scenario meets a first preset condition. The second acquisition module is used to acquire the target hardware indicators cached in the test device under the target scenario, wherein the target hardware indicators are time-related indicators. The second determining module is used to determine the function to be optimized from the set of objective functions when the target hardware indicators do not meet the second preset conditions, wherein the set of objective functions includes the function corresponding to the target scenario; An optimization module is used to execute optimization strategies for the function to be optimized in order to improve the performance of the application under test.

14. An electronic device, comprising a processor and a memory; The memory is used to store computer programs; The processor is configured to execute the computer program to implement the performance optimization method for the application as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, Used to store computer programs; The computer program causes the computer to perform a performance optimization method for the application as described in any one of claims 1 to 12.

Images