Performance test method and device, equipment, storage medium and program product

Abstract

The invention belongs to the technical field of computers, and particularly relates to a performance testing method and device, equipment, a storage medium and a program product. The method comprises the steps that in the running process of a target game, the starting time of at least one game frame, the running timestamp of at least one preset function and the running time consumption of each preset function are obtained; the game frame is used for representing an updating time interval of the game data; the preset function is a function operated by the processor in the operation process of the target game; based on the starting time of at least one game frame and the running timestamp of each preset function, determining the game frame to which the running time consumption of each preset function belongs; and generating a performance test result of the target game based on the game frame to which the running time consumption of each preset function belongs. According to the scheme, the high-time-consumption function in the single game frame can be quickly positioned to optimize the game program, so that the game optimization cost is reduced, the game optimization efficiency is improved, and the overall performance of the game is improved.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a performance testing method, apparatus, device, storage medium, and program product. Background Technology

[0002] With technological advancements and improved living standards, people have increasingly higher demands for gaming experiences. Frame rate (Frames Per Second, FPS) is a crucial indicator of game smoothness. Generally, a higher frame rate provides a smoother visual experience, while a lower frame rate can lead to stuttering and choppy gameplay. To improve frame rates, game developers often conduct statistical analysis of the time taken by the processor to execute functions in the game program, optimizing time-consuming functions to increase the overall frame rate.

[0003] Currently, statistical analysis of the time consumption of functions in game programs is often performed over a period of time, covering the overall time consumption. However, for game programs, during gameplay, in most cases only a single frame of game data might exhibit abnormal function time consumption. This requires a significant amount of time and effort to identify abnormally high-time-consuming functions within the overall time consumption statistics. This not only consumes substantial resources, increasing game optimization costs, but also leads to inefficient game optimization and a degraded gaming experience. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a performance testing method, apparatus, device, storage medium, and program product.

[0005] On one hand, embodiments of this application provide a performance testing method, the method comprising:

[0006] During the execution of the target game, the start time of at least one game frame and the execution timestamp of at least one preset function, as well as the execution time of each preset function, are obtained; the game frame is used to represent the time interval for updating game data; the preset function is the function executed by the processor during the execution of the target game;

[0007] Based on the start time of at least one game frame and the execution timestamp of each preset function, determine the game frame to which the execution time of each preset function belongs;

[0008] Based on the game frames to which the execution time of each preset function belongs, the performance test results of the target game are generated.

[0009] On the other hand, embodiments of this application also provide a performance testing apparatus, the apparatus comprising:

[0010] The acquisition module is used to acquire the start time of at least one game frame and the execution timestamp of at least one preset function, as well as the execution time of each preset function, during the running of the target game; the game frame is used to represent the update time interval of game data; the preset function is the function executed by the processor during the running of the target game;

[0011] The game frame determination module is used to determine the game frame to which the execution time of each preset function belongs, based on the start time of at least one game frame and the execution timestamp of each preset function.

[0012] The performance test result generation module is used to generate performance test results for the target game based on the game frames to which the execution time of each preset function belongs.

[0013] On the other hand, embodiments of this application also provide an electronic device for performance testing, the electronic device including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or at least one program being loaded and executed by the processor to implement the performance testing method as described above.

[0014] On the other hand, embodiments of this application also provide a computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or the at least one program is loaded and executed by a processor to implement the performance testing method as described above.

[0015] On the other hand, embodiments of this application also provide a computer program product, which, when executed by a processor, implements the performance testing method as described above.

[0016] The performance testing method, apparatus, device, storage medium, and program product proposed in this application acquire the start time of at least one game frame, the execution timestamp of at least one preset function, and the execution time of each preset function during the operation of the target game. Based on the start time of at least one game frame and the execution timestamp of each preset function, the game frame to which the execution time of each preset function belongs is determined. Then, based on the game frame to which the execution time of each preset function belongs, the performance test results of the target game are generated. This achieves statistical analysis of the execution time of functions in the game program within a single game frame, thereby quickly locating high-time-consuming functions in a single game frame to optimize the game program, reduce game optimization costs, improve game optimization efficiency, and ultimately improve the overall performance of the game. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram illustrating the implementation environment of a performance testing method according to an exemplary embodiment.

[0019] Figure 2 This is a flowchart illustrating a performance testing method according to an exemplary embodiment. Figure 1 .

[0020] Figure 3 This is a graphical representation of a performance test result according to an exemplary embodiment.

[0021] Figure 4 This is a flowchart illustrating a performance testing method according to an exemplary embodiment. Figure 2 .

[0022] Figure 5 This is a block diagram of a performance testing apparatus according to an exemplary embodiment.

[0023] Figure 6 This is a hardware structure block diagram of a server for a performance testing method provided according to an exemplary embodiment. Detailed Implementation

[0024] 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.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of the embodiments 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 embodiments of the present application described herein can be implemented in orders other than those illustrated or described herein. Thus, features defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments, unless otherwise stated, "a plurality of" means two or more. 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 includes 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.

[0026] To make the objectives, technical solutions, and advantages disclosed in the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this application and are not intended to limit the embodiments of this application.

[0027] After the game version development is completed, performance data will be collected for the target scene. When a high CPU usage issue occurs, function time consumption based on CPU sampling time will be collected for the high CPU usage scene. After collection, the distribution of high time consumption functions throughout the game can be seen, so as to carry out targeted optimization.

[0028] In related technologies, CPU time consumption statistics are often only performed over a period of time, making it impossible to sample and confirm the time consumption distribution of individual frames. This significantly increases the cost of identifying abnormally high-time-consuming functions. Moreover, during game execution, only one frame may exhibit abnormal function time consumption. This method of analyzing overall time consumption over a period of time greatly impacts the speed of game optimization iterations. Furthermore, the aforementioned statistical analysis methods also include the time consumption of various system root functions. However, these functions are not part of the game program's logical functionality, and including them in the statistics significantly slows down the analysis and optimization process.

[0029] In view of this, embodiments of this application propose a performance testing method, apparatus, device, storage medium, and program product. During the operation of a target game, the method acquires the start time of at least one game frame, the execution timestamp of at least one preset function, and the execution time of each preset function. Based on the start time of at least one game frame and the execution timestamp of each preset function, the method determines the game frame to which the execution time of each preset function belongs. Then, based on the game frame to which the execution time of each preset function belongs, the method generates the performance test results of the target game. This achieves statistical analysis of the execution time of functions in the game program within a single game frame, thereby quickly locating high-time-consuming functions in a single game frame to optimize the game program, reduce game optimization costs, improve game optimization efficiency, and ultimately enhance the overall performance of the game.

[0030] Figure 1 This is a schematic diagram illustrating the implementation environment of a performance testing method according to an exemplary embodiment. For example... Figure 1 As shown, the implementation environment may include at least a client 01 and a test terminal 02. The client 01 and the test terminal 02 may be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0031] In this embodiment, the client 01 can be a terminal device running the target game program. Optionally, the client 01 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smart voice interaction device, smart home appliance, smartwatch, vehicle terminal, aircraft, etc., but is not limited to these. This embodiment can be applied to various scenarios, including but not limited to rendering and displaying interactive information involved in various scenarios such as cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0032] In this embodiment, the test terminal 02 can be a terminal device that performs statistical analysis on the function execution time in the target game program. The test terminal 02 can be used to acquire the start time of at least one game frame, the execution timestamp of at least one preset function, and the execution time of each preset function during the operation of the target game. The test terminal 02 can also be used to determine the game frame to which the execution time of each preset function belongs based on the start time of at least one game frame and the execution timestamp of each preset function. The test terminal 02 can also be used to generate performance test results for the target game based on the game frame to which the execution time of each preset function belongs. Optionally, the test terminal 02 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smart voice interaction device, smart home appliance, smartwatch, vehicle terminal, aircraft, etc., but is not limited to these. In some embodiments, the test terminal 02 can also be a server. Optionally, the test terminal 02 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides 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, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0033] It should be noted that, Figure 1 This is just one example. Other implementation environments may also be included in other scenarios.

[0034] Figure 2 This is a flowchart illustrating a performance testing method according to an exemplary embodiment. Figure 1 This method can be used for Figure 1 In the implementation environment described in this specification, the method operation steps are as illustrated in the embodiments or flowcharts. However, based on conventional or non-inventive labor, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or server product execution, the method can be executed sequentially according to the embodiments or drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown in the embodiments or drawings... Figure 2 As shown, the method may include:

[0035] S101: During the running of the target game, obtain the start time of at least one game frame and the running timestamp of at least one preset function, as well as the running time of each preset function.

[0036] In this embodiment, when running the target game, the terminal device can execute the source files of the target game. Optionally, the target game can run directly on the terminal device, or it can run based on a host program on the terminal device. For example, if the target game is a mini-game, it can run through the runtime environment provided by the host program.

[0037] During gameplay, the target game updates game frames at a certain frequency. A game frame represents the time interval between game data updates. A game frame can be a time interval for game logic processing or a time interval for the game screen to be redrawn. The start time of a game frame refers to the time at which a frame of game data is generated. When performing performance testing on the target game, the start time of each game frame can be obtained to divide the game data into frames, thus allowing for performance evaluation within a single frame.

[0038] Preset functions are functions executed by the processor during the target game's runtime. The target game's source files contain several functions used to implement game logic or game visuals. During the target game's runtime, these functions are loaded and executed by the processor in the terminal device, thereby updating the game logic or game visuals. Furthermore, the target game requires the assistance of the terminal device's operating system. Therefore, during the target game's runtime, some functions from the operating system are also loaded and executed by the processor. For any given preset function, its execution by the processor takes a certain amount of time. The preset function's execution timestamp refers to the start and / or end time of the preset function being loaded and executed by the processor. The execution time of a preset function refers to the time elapsed from when the preset function is loaded and executed by the processor to when it finishes execution.

[0039] In this embodiment, the start time of at least one game frame, the execution timestamp of at least one preset function, and the execution time of each preset function can be obtained by performance sampling analysis of the functions run by the processor during the execution of the target game. Specifically, during the execution of the target game, performance sampling is performed on the functions run by the processor to obtain performance sampling data. By parsing and processing the performance sampling data, the start time of at least one game frame, the execution timestamp of at least one preset function, and the execution time of each preset function are obtained.

[0040] By sampling the performance of the functions run by the processor and parsing the obtained performance sampling data, key performance test data such as the start time of game frames, the execution timestamps of preset functions, and the execution time of preset functions can be obtained conveniently and quickly. Based on this data, game performance can be analyzed to locate performance bottlenecks in the target game, thereby optimizing the source files of the target game and improving the running efficiency of the target game.

[0041] For game programs, their running modes can include release mode and debug mode. When running a game program in release mode, in order to ensure the stability of game performance, optimized compilation options are usually used to remove all debugging information, thereby reducing memory consumption and improving running efficiency. When running in debug mode, the focus is more on debuggability and error detection, and compilation optimization is usually not used, so that clearer stack traces, variable information, etc. can be obtained during debugging.

[0042] In this embodiment, when sampling the performance of functions executed by the processor, the target game needs to be run in debug mode first. Then, while the target game is running in debug mode, performance sampling is performed on the functions executed by the processor to obtain performance sampling data. By running the target game in debug mode, the start and end times of function execution in the game program source file can be controlled and recorded more precisely, thereby obtaining more accurate execution time data for analysis of the target game.

[0043] When performing performance sampling on functions executed by the processor, a first sampling tool and a second sampling tool can be used to obtain performance sampling data. Specifically, during the target game's debug mode, performance sampling of the functions executed by the processor is performed using the first sampling tool to obtain first sampling data, and performance sampling of the functions executed by the processor is performed using the second sampling tool to obtain second sampling data. The first sampling data includes the execution timestamp of each preset function and the execution time of each preset function. The second sampling data includes the execution start time of a first target function, which is a function among at least one preset function that satisfies a first preset condition. Satisfying the first preset condition means that the first target function is a function executed when a game frame is updated; such functions are called every frame. By collecting the execution start time of the first target function, the time interval corresponding to each game frame can be determined. Then, based on the first and second sampling data, the performance sampling data is determined. Using the first sampling tool to collect the first sampling data and the second sampling tool to collect the second sampling data improves sampling efficiency. Meanwhile, the first sampled data is used to obtain the running timestamp of each preset function and the running time of each preset function, and the second sampled data is used to obtain the start time of at least one game frame, which can improve the efficiency of subsequent data analysis.

[0044] The first sampling data can be obtained by using a first sampling tool (such as SimplePerf) to perform performance sampling on the functions executed by the processor. The second sampling data can be obtained by using a second sampling tool (such as InsightTrace) to perform performance sampling on the functions executed by the processor. For game programs, this typically includes game source files and a game engine that runs the game source files. When performing performance sampling on the functions executed by the processor, the compilation configuration in the game engine can be modified to run the target game in debug mode, thus allowing the first and second sampling tools to be used to perform performance sampling on the functions executed by the processor.

[0045] As an example, taking the target game running on a preset operating system (such as Android) as an example, when using a first sampling tool (such as SimplePerf) to perform performance sampling on the functions running on the processor and obtain the first sampling data, the source files of the target game can be made into a debuggable state by modifying the attribute value of the debug attribute configuration (such as android:debuggable) in the game engine (such as setting android:debuggable to true), thereby facilitating the acquisition of various performance events (such as perf_event).

[0046] In some embodiments, the first performance sampling data is also used to obtain the call stack information of each preset function, so as to quickly locate the preset functions with high time consumption. Therefore, when performing performance sampling on the processor, it is necessary to collect the call stack information of each preset function. To achieve the collection of call stack information, a preset field (such as -fno-omit-frame-pointer) can be added to the game engine's compilation settings to prevent the game engine from optimizing away the function's frame pointer (FP) when running the target game's source file. -fno-omit-frame-pointer is a game engine option, mainly used to control whether the game engine omits the frame pointer during compilation. The frame pointer is a register used to point to the base address of the current stack frame. It is used to maintain the stack structure during function calls, helping the game engine generate debugging information and handle exceptions. By default, the game engine omits the frame pointer (using the -fno-omit-frame-pointer option) because this can improve the performance of the source file and reduce register pressure and memory access frequency. However, in this embodiment of the application, in order to collect call stack information, it is necessary to retain the stack frame pointer, so that the debugger can more easily traverse the stack frame to obtain more accurate call stack information.

[0047] By adding a preset field in the game engine's compilation settings, the stack frame pointer is preserved in a register, preventing other compilation optimization options (such as -O, -O2, -O3, -Os) from optimizing it away. For the stack frame pointer, each process's stack space is one frame, and the stack frame pointer points to the bottom of the current process's stack space. The stack pointer (SP) always points to the top of the stack. By tracing back the stack frames, the call process of the source file and the parameters used during the call can be obtained, facilitating the capture of complete call stack information.

[0048] In addition, game engines typically include preset macros to enable or disable specific functions. For example, when a preset macro (such as `UE_TRACE_ENABLED`) is defined, the game engine includes debug source files, and the executable file compiled from the preset macro outputs corresponding information at runtime. When a preset macro (such as `UE_TRACE_ENABLED`) is not defined, the game engine ignores the debug source files, thereby reducing the game program size and improving performance. When a preset macro (such as `MISCTRACE_ENABLED`) is defined, the game engine includes debug source files for specific modules or systems, and the executable file compiled from the preset macro outputs corresponding information at runtime. When a preset macro (such as `MISCTRACE_ENABLED`) is not defined, the game engine ignores those debug source files, thereby reducing the game program size and improving performance. When using a second sampling tool (such as SimplePerf) to perform performance sampling on the functions running on the processor and obtain second sampling data, you can enable the performance sampling function of the entire second sampling tool and enable the follow-up collection function of the time consumption information for each frame by defining the preset macros in the game engine (such as UE_TRACE_ENABLED and / or MISCTRACE_ENABLED) as preset values ​​(such as 1).

[0049] In some embodiments, when sampling the performance of functions executed by the processor, it is also necessary to enable the data acquisition function based on the instruction file.

[0050] As an example, the collection of the first sampled data can be achieved by running a first instruction file (such as a Python instruction file) using the game engine. The first instruction file sets the first preset instructions, such as `python app_profiler.py -p com.tencent -r " -e task-clock"` and `--call-graph fp --duration 60" -lib.\lib -o perf.data --f 4000`, to collect the first sampled data from the target game scene. Here, `python app_profiler.py` indicates that the first instruction file is a Python script, which needs to be run using a Python interpreter. `-p com.tencent` specifies that the process name for performance data collection is "com.tencent". `-r` specifies additional parameters for the running application, which are passed to the first sampling tool. `-e task-clock` uses the first sampling tool to capture data from task events (task-clock), where task events represent the actual processor time occupied by the target task. `--call-graph fp` is the default method used by the first sampling tool. It requires disabling compiler optimizations that affect the stack trace (such as `-fno-omit-frame-pointer`), otherwise, incorrect stack information may not be obtained. `--duration 60` sets the sampling duration to 60 seconds, but other durations are also possible. `-f 4000` indicates that a sampling frequency of 4000 Hz is used for data acquisition, but other sampling frequencies are also possible. After a period of performance data acquisition, the first sampled data can be obtained and stored in the `perf.data` file.

[0051] As another example, the acquisition of second-sampled data can be achieved by using a game engine to run a second command file (such as UE4CommandLine.txt). By adding a second preset command (such as -trace=Frame -tracefile=perf.utrace) to the second command file, corresponding second-sampled data (such as a Trace file) can be recorded during the target game's startup process. Here, "-trace=Frame" represents capturing the time consumption information for each game frame, and "perf.utrace" represents the filename of the generated second-sampled data.

[0052] Using the above methods, performance sampling of the functions executed by the processor can be performed during the debugging mode of the target game to obtain the first sample data and the second sample data.

[0053] It should be noted that when the first sampling tool performs performance sampling on the functions run by the processor, it can obtain the execution time and timestamps of each preset function without pre-labeling the functions being sampled. However, since the data collected by the first sampling tool is the execution timestamps of all preset functions run by the processor during the target game's debug mode, and there is usually a large amount of preset function data, finding the first target function from all preset functions requires considerable time. Meanwhile, when the second sampling tool performs performance sampling on the functions run by the processor, it needs to pre-label the functions being sampled in order to collect the corresponding function's execution timestamp. This results in all preset functions needing to be pre-labeled if only the second sampling tool is used for performance sampling, which is time-consuming, costly, and inefficient. Therefore, this embodiment uses the first sampling tool to collect the execution time and timestamps of all preset functions, while using the second sampling tool to collect the timestamps of the first target function. This improves the efficiency of data collection and subsequent data analysis, and reduces performance testing costs.

[0054] In this embodiment, after collecting the first and second sampled data, the start time of at least one game frame, the runtime timestamp of at least one preset function, and the runtime of each preset function can be obtained by parsing the first and second sampled data. Specifically, the runtime timestamp of each preset function and the runtime of each preset function are obtained by parsing the first sampled data. The start time of the first objective function is obtained by parsing the second sampled data. The start time of the first objective function is used as the start time of at least one game frame. By parsing the first and second sampled data, key performance analysis data such as the start time of the game frame, the runtime timestamp of the preset function, and the runtime are obtained, which can improve the efficiency of data analysis and reduce the cost of performance testing.

[0055] In some optional embodiments, the first sampling data also includes call stack information for each preset function. By parsing the first sampling data, call stack information for each preset function can be obtained, which is used to characterize the parent-child relationship between each preset function. After obtaining the call stack information for each preset function, a second target function satisfying a second preset condition is determined from at least one preset function. Satisfying the second preset condition means that the second target function is a function that does not belong to the game program, such as a system-level root function. The execution time of such functions cannot be used as a basis for game optimization, so such functions can be filtered out and eliminated. Specifically, the call stack information corresponding to the second target function is removed from the call stack information of at least one preset function to obtain target call stack information; the target call stack information is used to generate the performance test results of the target game. By determining the second target function from the preset functions and removing the call stack information corresponding to the second target function, various system-level root functions can be filtered out, avoiding the performance testing costs caused by various system functions and improving performance testing efficiency.

[0056] In practical applications, the data in the first sample data is stored according to a preset data structure. Therefore, after obtaining the first sample data, it needs to be parsed to obtain its content. Optionally, a first script file can be used to read the content of the first sample data. The first sample data stores examples of performance sampling of the processor during game execution, i.e., performance sampling data corresponding to each preset function. When parsing the first sample data, a loop statement (such as a while loop) can be set in the first script to parse the first sample data. Each example in the first sample data can be obtained through a getter statement (such as GetNextSample). For any example, i.e., any preset function, the specific time consumption information of the current sample can be obtained through a sample event getter statement (such as GetEventOfCurrentSample), including the execution timestamp and runtime of the current preset function. The specific function name of the current preset function is obtained through sample name retrieval statements (such as `GetSymbolOfCurrentSample`), facilitating the symbolic representation of the abstract function algorithm and reducing the analysis cost of subsequent processes. The call stack information of the current preset function is obtained through sample call chain retrieval statements (such as `GetCallChainOfCurrentSample`), providing a complete upper-level call stack. During the process of obtaining the call stack information of the current preset function, all parent functions and superparent functions of system functions (such as `UgameEngine::Tick`) can be discarded to improve the efficiency of subsequent analysis. Furthermore, the thread of the current preset function can be obtained through thread retrieval statements (such as `get_or_add_thread`). After obtaining the above parsing information of the current preset function, this information can be saved to the sampling library of the thread to which the current preset function belongs. The saved information includes the symbolic parsing call stack, function start time, function end time, and processor execution information for running the current preset function. By repeating the above process, the parsing results of all preset functions can be obtained.

[0057] Game frames can be defined relative to either the logic thread or the rendering thread. In other words, a game frame can be either a logic frame or a rendering frame. A logic frame refers to the time interval of game logic processing; it includes all updates to the game world, such as character positions, enemy behavior, and the simulation of physics effects. The updating of logic frames is usually controlled by the game's main loop and executed at a certain frequency. This frequency can be the same as or different from the game's actual frame rate. The update frequency of logic frames has a significant impact on the game's responsiveness and smoothness. A rendering frame, on the other hand, refers to the number of times the image on the screen is redrawn. Each time a rendering frame is updated, the game draws a new image onto the screen, which directly determines the smoothness of the game's visuals. Generally, the more rendering frames, the smoother the visuals appear. In games, logic frames and rendering frames are usually synchronized; that is, a rendering occurs after each logic update. However, in some cases, these two may be decoupled. Therefore, the preset functions in the target game's runtime can be functions corresponding to either the logic thread or the rendering thread. Similarly, performance analysis of a target game can be performed by analyzing the runtime of preset functions corresponding to logical frames or by analyzing the runtime of preset functions corresponding to rendering frames.

[0058] As an optional implementation, the first objective function is a logical thread function, and the game frame is a logical frame. By parsing the second sampled data, the start time of each logical frame can be obtained. Specifically, the second sampled data is parsed to obtain the execution start time of the logical thread function. This execution start time of the logical thread function is used as the start time of each logical frame. By parsing the execution time of the logical thread function, the time interval corresponding to each game frame can be determined. This allows for runtime analysis of the preset function corresponding to the logical thread, thereby optimizing the logical thread.

[0059] As an alternative implementation, the first objective function is the rendering thread function, and the game frame is the rendering frame. By parsing the second sampled data, the start time of each rendering frame can be obtained. Specifically, the second sampled data is parsed to obtain the start time of the rendering thread function. The start time of the logic thread function is used as the start time of each rendering frame. By parsing the execution time of the rendering thread function, the time interval corresponding to each game frame can be determined. This allows for time consumption analysis of the preset function corresponding to the rendering thread, thereby optimizing the rendering thread.

[0060] In practical applications, a parser (such as UtraceReader) can be used to parse and read the second sampled data. When parsing and reading the second sampled data, loop statements (such as for loops) can be used to parse the data in the logic thread and / or rendering thread to obtain logical frames and / or rendering frames. When processing logical frames, a preset data structure (such as utrace_data.game_frame_scopes) is continuously searched to obtain the start and end times of each logical frame, thus obtaining a complete logical frame. After obtaining each logical frame, the time interval information of each logical frame, such as the start and end times, can be saved in the parsing result file (such as utrace_game_thread). Similarly, when processing rendering frames, a preset data structure (such as utrace_data.game_frame_scopes) is continuously searched to obtain the start and end times of each rendering frame, thus obtaining a complete rendering frame. After obtaining each rendering frame, the time interval information of each rendering frame, such as the start and end times, can be saved in the parsing result file (such as utrace_render_thread).

[0061] S103: Based on the start time of at least one game frame and the runtime timestamp of each preset function, determine the game frame to which the runtime of each preset function belongs.

[0062] In this embodiment, after obtaining the start time of each game frame and the runtime timestamp of each preset function, the game frame to which the runtime of each preset function belongs can be determined. Specifically, the time interval between the start times of two game frames is considered one frame. Then, based on the runtime timestamp of each preset function, the runtime of each preset function is mapped to the corresponding time interval of each game frame. As an example, a preset function A, through parsing the first sampled data, is found to start running at 55ms, with a runtime of 10ms. Through parsing the second sampled data, the start times of two adjacent game frames are obtained as 50ms and 90ms. Therefore, the period from 50ms to 89ms constitutes one game frame, and the runtime of preset function A, 10ms, can be determined as the runtime corresponding to that game frame.

[0063] In practical applications, after obtaining the parsing results of the first and second sampled data, the two parsing results can be summarized and transcoded to map the execution time information of the preset functions to the time interval corresponding to each game frame. Specifically, a first loop statement (such as a for loop) is used to iterate through all threads. Since only the logic thread and the rendering thread in the target game have the concept of frames, the game frame only contains information about these two threads. Then, a second loop statement (such as a while loop) is used to summarize the data for the entire single frame range. By parsing the second sampled data, the start and end times of each frame can be obtained. By parsing the first sampled data, the execution time information of each function along the entire timeline can be obtained. These two sets of data are then summarized using a summary instruction (such as write_one_stack_frame) to summarize the execution time of the preset functions within the start and end times of each frame.

[0064] S105: Generate performance test results for the target game based on the game frame to which the execution time of each preset function belongs.

[0065] In this embodiment, after obtaining the game frame to which the execution time of each preset function belongs, the performance test results of the target game can be generated by combining the call stack information corresponding to each preset function. Specifically, the performance test results of the target game are generated by combining the game frames to which the execution time of each preset function belongs according to the target call stack information. By associating the game frames to which the execution time of each preset function belongs with the target call stack information, it is possible to more accurately identify which parts of the target game program consume more execution time, which helps to quickly locate performance bottlenecks and then take corresponding optimization measures.

[0066] In some embodiments, when generating performance test results for the target game, the results can also be displayed using a graphical tool to facilitate quick and easy identification of time-consuming preset functions. Specifically, when generating performance test results for the target game, the game frames to which the execution time of each preset function belongs are combined according to the target call stack information to obtain a combined result. The combined result is then written to a test result file in a preset format that the graphical tool can read. The test result file is then parsed using a graphical tool to obtain the performance test results for the target game. By writing the combined result to the test result file in a preset format, the test results can be displayed using a graphical tool. This graphical display makes the performance data more intuitive, and the graphical performance test structure allows for rapid identification of time-consuming preset functions and their positions in the call chain, enabling targeted optimization.

[0067] In practical applications, by summarizing the start and end times of each acquired frame and the time consumption information of each function along the entire timeline, it is possible to statistically analyze the execution time of a preset function within a single frame. The performance test results are then saved by writing the statistical results and call stack information to a test result file according to a preset format. During the writing process, a preset writing tool (such as framepro_writer) can be used to achieve the preset format (such as framepro format). Finally, the entire test result file is written according to the preset format for convenient graphical display.

[0068] Figure 3 This is a graphical representation of a performance test result according to an exemplary embodiment, such as... Figure 3 As shown in the graphical representation of the performance test results, each game frame is displayed sequentially according to its frame number, such as frame number 427, frame number 428, frame number 429, etc. For each game frame, the execution time is displayed on the frame itself, such as frame time: 22.14ms. For any given game frame, the preset functions displayed below it can be arranged according to the call stack. For any preset function, the longer its execution time, the longer the corresponding block in the graph. Furthermore, each game frame can be a logic frame, and the call stack information displayed below it represents the preset functions corresponding to the logic thread. Alternatively, the game frame can be a rendering frame, and the call stack information displayed below it represents the preset functions corresponding to the rendering thread.

[0069] Based on graphical performance test results, it is possible to quickly locate frames with high execution time and functions with high execution time. For example... Figure 3 As shown, when a high-time-consuming game frame is suddenly encountered, such as frame number 429 with a frame duration of 30.37ms, its duration is significantly higher than other frames. In this case, the high-time-consuming function can be analyzed by examining the specific function call stack corresponding to that frame and the execution time of each preset function in the call stack. From top to bottom, the functions are parent functions, child functions, etc., and the length of each function represents its relative execution time, thus intuitively locating the high-time-consuming function and improving game optimization efficiency.

[0070] The above technical solutions enable sampling and statistics of processor execution time for preset functions within a single frame. This allows developers to focus their analysis on various high-time-consuming frames, accelerating the analysis and localization of stuttering frames. For the preset function statistics within each single frame, symbolic representation of various preset functions facilitates the interpretation of performance test results and improves performance analysis efficiency. Filtering the acquired overall function call stack removes various system root functions, avoiding additional analysis costs caused by non-game logic.

[0071] Figure 4 This is a flowchart illustrating a performance testing method according to an exemplary embodiment. Figure 2 ,like Figure 4 As shown, when performing performance testing on a target game, the game engine's compilation configuration can be set first to run the target game in debug mode. For example, the game's attributes can be configured as adjustable, meaning the target game's source files are set to an adjustable state to facilitate the subsequent collection of the first sample data. Simultaneously, macro control is enabled to facilitate the subsequent collection of the second sample data. Next, while the target game is running in debug mode, performance sampling is performed on the functions executed by the processor, obtaining the first and second sample data. Then, the first sample data is parsed within a single frame, yielding the corresponding parsing results. The second sample data is also parsed within a single frame, yielding the corresponding parsing results. Next, the parsing results of these two sets of sample data are merged according to timestamps to obtain a summary result. Finally, the summary result is written to a performance test result file and saved according to a preset format.

[0072] The performance testing method described in this application realizes processor time consumption sampling statistical analysis based on a single frame range. It enables statistical analysis of the time consumption functions sampled by various processors on a single frame range. By filtering various system-level root functions and function symbolization, it allows R&D personnel to quickly focus on various high-time-consuming functions, greatly accelerating the overall R&D efficiency.

[0073] This application also provides a performance testing device. Figure 5 This is a block diagram of a performance testing apparatus according to an exemplary embodiment, such as... Figure 5 As shown, the device may include at least:

[0074] The acquisition module 201 is used to acquire, during the running of the target game, the start time of at least one game frame, the running timestamp of at least one preset function, and the running time of each preset function; the game frame is used to represent the update time interval of game data; the preset function is the function executed by the processor during the running of the target game;

[0075] The game frame determination module 203 is used to determine the game frame to which the execution time of each preset function belongs based on the start time of at least one game frame and the execution timestamp of each preset function.

[0076] The performance test result generation module 205 is used to generate performance test results for the target game based on the game frame to which the execution time of each preset function belongs.

[0077] In some optional embodiments, the acquisition module includes:

[0078] The sampling submodule is used to perform performance sampling on the functions executed by the processor during the running of the target game, and obtain performance sampling data.

[0079] The parsing submodule is used to parse and process the performance sampling data to obtain the start time of at least one game frame, the runtime timestamp of at least one preset function, and the runtime of each preset function.

[0080] In some optional embodiments, the sampling submodule includes:

[0081] The runtime unit is used to run the target game in debug mode;

[0082] The sampling unit is used to perform performance sampling on the functions executed by the processor during the target game's debug mode, and obtain performance sampling data.

[0083] In some optional embodiments, the sampling unit includes:

[0084] The sampling subunit is used to perform performance sampling on the functions run by the processor based on a first sampling tool to obtain first sampling data, and to perform performance sampling on the functions run by the processor based on a second sampling tool to obtain second sampling data during the debugging mode of the target game. The first sampling data includes the execution timestamp of each preset function and the execution time of each preset function. The second sampling data includes the execution start time of the first target function. The first target function is a function that satisfies a first preset condition among at least one preset function.

[0085] The performance sampling data determination subunit is used to determine performance sampling data based on the first sampling data and the second sampling data.

[0086] In some optional embodiments, the parsing submodule includes:

[0087] The first parsing unit is used to parse and process the first sampled data to obtain the running timestamp of each preset function and the running time of each preset function;

[0088] The second parsing unit is used to parse and process the second sampled data to obtain the start time of the first objective function.

[0089] The game frame start time determination unit is used to determine the start time of the execution of the first objective function as the start time of at least one game frame.

[0090] In some optional embodiments, the first sampling data further includes call stack information for each preset function; the call stack information is used to characterize the parent-child relationship between each preset function; the apparatus further includes:

[0091] The first parsing unit is used to parse and process the first sampled data to obtain the call stack information of each preset function;

[0092] The second objective function determination unit is used to determine a second objective function that satisfies a second preset condition from at least one preset function;

[0093] The target call stack information determination unit is used to remove the call stack information corresponding to the second target function from the call stack information of at least one preset function to obtain the target call stack information; the target call stack information is used to generate the performance test results of the target game.

[0094] In some optional embodiments, the first objective function is a logical thread function; the game frame is a logical frame; the second parsing unit includes:

[0095] The logical thread function execution start time determination subunit is used to parse and process the second sampled data to obtain the execution start time of the logical thread function; the execution start time of the logical thread function is used to obtain the start time of at least one logical frame.

[0096] In some optional embodiments, the first objective function is a rendering thread function; the game frame is a rendering frame; the second parsing unit includes:

[0097] The rendering thread function start time determination subunit is used to parse and process the second sampled data to obtain the start time of the rendering thread function; the start time of the rendering thread function is used to obtain the start time of at least one rendering frame.

[0098] In some optional embodiments, the performance test result generation module includes:

[0099] The performance test result generation submodule is used to combine the game frames to which the execution time of each preset function belongs according to the target call stack information to generate the performance test results of the target game.

[0100] In some optional embodiments, the performance test result generation submodule includes:

[0101] The combination unit is used to combine the game frames to which the execution time of each preset function belongs, according to the target call stack information, to obtain the combination result;

[0102] The writing unit is used to write the combined results into the test result file according to a preset format.

[0103] The test result file parsing unit is used to parse the test result file using a graphical tool to obtain the performance test results of the target game.

[0104] It should be noted that the embodiments of the performance testing device provided in this application are based on the same inventive concept as the embodiments of the performance testing method described above.

[0105] This application also provides an electronic device for performance testing, which includes a processor and a memory. The memory stores at least one instruction or at least one program. The processor loads and executes the at least one instruction or at least one program to implement the performance testing method provided in any of the above embodiments.

[0106] Embodiments of this application also provide a computer-readable storage medium that can be disposed in a terminal to store at least one instruction or at least one program for implementing a performance testing method in the method embodiments, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the performance testing method provided in the above method embodiments.

[0107] Optionally, in the embodiments of this specification, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program source files, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0108] The memory described in this specification can be used to store software programs and modules. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory. The memory may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for functions, etc.; the data storage area may store data created based on the use of the device, etc. Furthermore, the memory may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory may also include a memory controller to provide the processor with access to the memory.

[0109] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the performance testing method provided in the above-described method embodiments.

[0110] The methods and embodiments provided in this application can be executed on a terminal, computer terminal, server, or similar computing device. Taking running on a server as an example, Figure 6 This is a hardware structure block diagram of a server for a performance testing method provided according to an exemplary embodiment. For example... Figure 6 As shown, the server 300 can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 310 (CPUs 310 may include, but are not limited to, microprocessors (MCUs) or programmable logic devices (FPGAs), a memory 330 for storing data, and one or more storage media 320 (e.g., one or more mass storage devices) for storing application programs 323 or data 322. The memory 330 and storage media 320 may be temporary or persistent storage. The program stored in the storage media 320 may include one or more modules, each module may include a series of instruction operations on the server. Furthermore, the CPU 310 may be configured to communicate with the storage media 320 and execute the series of instruction operations stored in the storage media 320 on the server 300. Server 300 may also include one or more power supplies 360, one or more wired or wireless network interfaces 350, one or more input / output interfaces 340, and / or one or more operating systems 321, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0111] The input / output interface 340 can be used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of server 300. In one example, the input / output interface 340 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the input / output interface 340 may be a radio frequency (RF) module for wireless communication with the Internet.

[0112] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, server 300 may also include... Figure 6 The more or fewer components shown, or having the same Figure 6 The different configurations shown.

[0113] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0114] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and server embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0115] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0116] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A performance testing method, characterized in that, The method includes: During the execution of the target game, the start time of at least one game frame and the execution timestamp of at least one preset function, as well as the execution time of each preset function, are obtained; the game frame is used to represent the update time interval of game data; the preset function is a function executed by the processor during the execution of the target game; Based on the start time of at least one of the game frames and the execution timestamp of each preset function, determine the game frame to which the execution time of each preset function belongs; Based on the game frame to which the execution time of each preset function belongs, the performance test results of the target game are generated.

2. The method according to claim 1, characterized in that, The step of obtaining the start time of at least one game frame and the execution timestamp of at least one preset function, as well as the execution time of each preset function, during the operation of the target game includes: During the execution of the target game, performance samples are taken from the functions executed by the processor to obtain performance sample data; The performance sampling data is parsed to obtain the start time of at least one game frame, the runtime timestamp of at least one preset function, and the runtime of each preset function.

3. The method according to claim 2, characterized in that, The process of sampling the performance of functions executed by the processor during the target game's execution to obtain performance sampling data includes: Run the target game in debug mode; During the running of the target game in debug mode, performance sampling is performed on the functions executed by the processor to obtain performance sampling data.

4. The method according to claim 3, characterized in that, The process of sampling the performance of functions executed by the processor during the debugging mode of the target game to obtain performance sampling data includes: During the execution of the target game in debug mode, performance sampling is performed on the functions executed by the processor using a first sampling tool to obtain first sampling data, and performance sampling is performed on the functions executed by the processor using a second sampling tool to obtain second sampling data. The first sampling data includes the execution timestamp of each preset function and the execution time of each preset function. The second sampling data includes the execution start time of the first target function. The first target function is at least one of the preset functions that satisfies a first preset condition. The performance sampling data is determined based on the first sampling data and the second sampling data.

5. The method according to claim 4, characterized in that, The step of parsing the performance sampling data to obtain the start time of at least one game frame, the runtime timestamp of at least one preset function, and the runtime of each preset function includes: The first sampled data is parsed to obtain the running timestamp of each preset function and the running time of each preset function; The second sampled data is parsed and processed to obtain the start time of the first objective function. The start time of the execution of the first objective function is used as the start time of at least one of the game frames.

6. The method according to claim 5, characterized in that, The first sampled data also includes call stack information for each of the preset functions; The call stack information is used to characterize the parent-child relationship between each of the preset functions; the method further includes: The first sampled data is parsed to obtain the call stack information of each preset function; Determine a second objective function that satisfies the second preset condition from at least one of the preset functions; The call stack information corresponding to the second target function is removed from the call stack information of at least one of the preset functions to obtain the target call stack information; the target call stack information is used to generate the performance test results of the target game.

7. The method according to claim 5, characterized in that, The first objective function is a logical thread function; The game frame is a logical frame; the step of parsing the second sampled data to obtain the start time of the first objective function includes: The second sampled data is parsed and processed to obtain the start time of the execution of the logical thread function; The start time of the execution of the logical thread function is used to obtain the start time of at least one of the logical frames.

8. The method according to claim 5, characterized in that, The first objective function is the rendering thread function; The game frame is a rendering frame; the step of parsing the second sampled data to obtain the start time of the first objective function includes: The second sampled data is parsed and processed to obtain the start time of the rendering thread function. The start time of the rendering thread function is used to obtain the start time of at least one of the rendering frames.

9. The method according to claim 6, characterized in that, The process of generating performance test results for the target game based on the game frame to which the execution time of each preset function belongs includes: The game frames to which the execution time of each preset function belongs are combined and processed according to the target call stack information to generate the performance test results of the target game.

10. The method according to claim 9, characterized in that, The step of combining and processing the game frames to which the execution time of each preset function belongs according to the target call stack information to generate the performance test results of the target game includes: The game frames to which the execution time of each preset function belongs are combined according to the target call stack information to obtain the combined result; The combined results are written into a test result file according to a preset format; The performance test results of the target game are obtained by parsing the test result file using a graphical tool.

11. A performance testing device, characterized in that, The device includes: The acquisition module is used to acquire, during the running of the target game, the start time of at least one game frame, the running timestamp of at least one preset function, and the running time of each preset function; the game frame is used to represent the update time interval of game data; the preset function is a function executed by the processor during the running of the target game; The game frame determination module is used to determine the game frame to which the execution time of each preset function belongs based on the start time of at least one game frame and the execution timestamp of each preset function. The performance test result generation module is used to generate the performance test results of the target game based on the game frame to which the execution time of each preset function belongs.

12. An electronic device for performance testing, characterized in that, The device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded by the processor and executed by the performance testing method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction or at least one program, which is loaded and executed by a processor to implement the performance testing method as described in any one of claims 1-10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the performance testing method according to any one of claims 1-10.

Images