Performance analysis method and device for model-driven low-code platform and storage medium

Abstract

The invention provides a performance analysis method and device for a model-driven low-code platform and a storage medium, and belongs to the field of computers.The method comprises the steps that a network module of a browser is used for analyzing a page initialization stage, and an initialization loading bottleneck is determined; analyzing a model processing stage by utilizing a network module and a performance module of the browser, and determining a model processing bottleneck; analyzing a component loading and page rendering stage by utilizing a network module and a performance module of the browser, and determining a rendering bottleneck; based on the initialization loading bottleneck, the model processing bottleneck and the rendering bottleneck, comprehensive performance analysis is conducted, and key blocking points in the whole page loading process are determined. Through the method provided by the invention, the key blocking point can be accurately positioned, and the application development quality is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a performance analysis method for a model-driven low-code platform, a performance analysis device for a model-driven low-code platform, a processor, a machine-readable storage medium, and a computer program product. Background Technology

[0002] With the rapid development of information technology, enterprises have an ever-increasing demand for application software, while also placing higher demands on development costs and efficiency. Against this backdrop, low-code platforms have emerged. Low-code platforms aim to enable business users who are proficient in business but lack coding skills to build pages on demand through drag-and-drop visual interaction, with little or no code required. This model significantly reduces the barrier to entry for application development, communication costs, and development cycles, and offers advantages such as simple deployment and convenient maintenance.

[0003] Modern low-code platforms widely adopt a model-driven architecture. In this architecture, page generation and rendering are driven by model data. A typical model-driven page usually consists of two main parts: model data and UI design. The former defines the data structure and logic required for page display, while the latter defines the specific presentation of page elements. While this architecture improves development flexibility and efficiency, it also introduces a relatively complex page loading process, putting it under pressure for performance optimization.

[0004] Performance analysis is a crucial step in optimizing page loading experience. It involves analyzing the page loading process in the browser to obtain time data for each stage, thereby identifying performance bottlenecks. An efficient performance analysis solution can help developers save significant effort and quickly pinpoint the root cause of problems.

[0005] In existing technologies, traditional code-based tracking solutions are difficult to implement due to the dynamic compilation characteristics of low-code platforms, while browser-provided analysis tools, due to their versatility and complexity, cannot effectively locate specific bottlenecks in the model-driven loading chain unique to low-code pages. Summary of the Invention

[0006] The purpose of this application is to provide a performance analysis method, apparatus, processor, storage medium, and machine-readable storage medium for a model-driven low-code platform.

[0007] To achieve the above objectives, the first aspect of this application provides a performance analysis method for a model-driven low-code platform. The method includes: analyzing the page initialization phase using the browser's network module to identify initialization loading bottlenecks; wherein the initialization loading bottlenecks include file requests exceeding a preset number of requests within a preset time window or requests with a single request duration exceeding a preset duration; analyzing the model processing phase using the browser's network and performance modules to identify model processing bottlenecks; wherein the model processing bottlenecks include tasks with execution times exceeding a set duration or processing blockages caused by device resource consumption; analyzing the component loading and page rendering phases using the browser's network and performance modules to identify rendering bottlenecks; wherein the rendering bottlenecks include: component loading redundancy, rendering timing discrepancies, animation frame rendering times exceeding a preset time, or code logic blockages; and performing a comprehensive performance analysis based on the initialization loading bottlenecks, the model processing bottlenecks, and the rendering bottlenecks to identify key blockages in the overall page loading process.

[0008] In this embodiment of the application, the rendering bottleneck includes code logic blocking points; determining the rendering bottleneck includes: acquiring page screenshots at different time intervals, visually displaying the rendering status of the page in different time intervals to locate the time interval of the code logic blocking point; and determining the code logic blocking point based on the time interval of the code logic blocking point.

[0009] In this embodiment of the application, determining the code logic blocking point based on the time interval of the code logic blocking point includes: analyzing the task execution interval and time consumption of the main thread based on the time interval of the code logic blocking point, and locating the specific execution function that causes the long task to be generated, so as to determine the code logic blocking point.

[0010] In this embodiment of the application, the rendering bottleneck includes an anomaly where the animation frame rendering time exceeds a preset time; determining the rendering bottleneck includes: analyzing the rendering time of the page animation to determine the anomaly where the animation frame rendering time exceeds the preset time.

[0011] In this embodiment of the application, the step of performing comprehensive performance analysis based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck to determine the key blocking points in the overall page loading process includes: constructing a performance dependency graph, which is used to characterize the dependency relationship between the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck; and based on the performance dependency graph, determining the loading time impact weights of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck, respectively, to determine the key blocking points in the overall page loading process.

[0012] In this embodiment, constructing the performance dependency graph includes: taking file requests whose number of requests exceeds a preset number or whose single request duration exceeds a preset duration within a preset time window in the initialization loading bottleneck as the starting node of the graph; taking tasks or resource consumption blocking points in the model processing bottleneck whose execution time exceeds a set duration as intermediate processing nodes of the graph; taking component loading redundancy, rendering timing not conforming to expectations, animation frame rendering time exceeding a preset time, or code logic blocking points in the rendering bottleneck as downstream nodes of the graph; and establishing the dependency relationship between the starting node, intermediate processing nodes, and downstream nodes.

[0013] In this embodiment of the application, the step of determining the loading time impact weights of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck based on the performance dependency graph, in order to determine the key blocking points in the overall page loading process, includes: determining at least one critical path from the starting node to the downstream node, and calculating the total time consumption of each critical path; obtaining the time consumption of each bottleneck node on each critical path; calculating the impact weight of each bottleneck node based on the time consumption of each bottleneck node and the total time consumption of the critical path in which it is located; and determining the bottleneck node with the largest impact weight as the key blocking point.

[0014] A second aspect of this application provides a performance analysis device for a model-driven low-code platform. The device includes: an initialization loading bottleneck determination module, used to analyze the page initialization phase using the browser's network module to determine initialization loading bottlenecks; wherein the initialization loading bottlenecks include file requests with a number exceeding a preset number within a preset time window or requests with a single request duration exceeding a preset duration; a model processing bottleneck determination module, used to analyze the model processing phase using the browser's network and performance modules to determine model processing bottlenecks; wherein the model processing bottlenecks include tasks with execution times exceeding a set duration or processing blockages caused by device resource consumption; a rendering bottleneck determination module, used to analyze the component loading and page rendering phases using the browser's network and performance modules to determine rendering bottlenecks; wherein the rendering bottlenecks include: component loading redundancy, rendering timing discrepancies, animation frame rendering times exceeding a preset time, or code logic blockages; and a critical blockage point determination module, used to perform comprehensive performance analysis based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck to determine critical blockage points in the overall page loading process.

[0015] In this embodiment of the application, the rendering bottleneck includes code logic blocking points; determining the rendering bottleneck includes: acquiring page screenshots at different time intervals, visually displaying the rendering status of the page in different time intervals to locate the time interval of the code logic blocking point; and determining the code logic blocking point based on the time interval of the code logic blocking point.

[0016] In this embodiment of the application, determining the code logic blocking point based on the time interval of the code logic blocking point includes: analyzing the task execution interval and time consumption of the main thread based on the time interval of the code logic blocking point, and locating the specific execution function that causes the long task to be generated, so as to determine the code logic blocking point.

[0017] In this embodiment of the application, the rendering bottleneck includes an anomaly where the animation frame rendering time exceeds a preset time; determining the rendering bottleneck includes: analyzing the rendering time of the page animation to determine the anomaly where the animation frame rendering time exceeds the preset time.

[0018] In this embodiment of the application, the step of performing comprehensive performance analysis based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck to determine the key blocking points in the overall page loading process includes: constructing a performance dependency graph, which is used to characterize the dependency relationship between the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck; and based on the performance dependency graph, determining the loading time impact weights of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck, respectively, to determine the key blocking points in the overall page loading process.

[0019] In this embodiment, constructing the performance dependency graph includes: taking file requests whose number of requests exceeds a preset number or whose single request duration exceeds a preset duration within a preset time window in the initialization loading bottleneck as the starting node of the graph; taking tasks or resource consumption blocking points in the model processing bottleneck whose execution time exceeds a set duration as intermediate processing nodes of the graph; taking component loading redundancy, rendering timing not conforming to expectations, animation frame rendering time exceeding a preset time, or code logic blocking points in the rendering bottleneck as downstream nodes of the graph; and establishing the dependency relationship between the starting node, intermediate processing nodes, and downstream nodes.

[0020] In this embodiment of the application, the step of determining the loading time impact weights of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck based on the performance dependency graph, in order to determine the key blocking points in the overall page loading process, includes: determining at least one critical path from the starting node to the downstream node, and calculating the total time consumption of each critical path; obtaining the time consumption of each bottleneck node on each critical path; calculating the impact weight of each bottleneck node based on the time consumption of each bottleneck node and the total time consumption of the critical path in which it is located; and determining the bottleneck node with the largest impact weight as the key blocking point.

[0021] A third aspect of this application provides a processor configured to execute the performance analysis method for the model-driven low-code platform described above.

[0022] A fourth aspect of this application provides a machine-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the performance analysis method for a model-driven low-code platform described above.

[0023] The fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the performance analysis method for the model-driven low-code platform described above.

[0024] The technical solution provided in this application has at least the following technical effects: This application's performance analysis method for model-driven low-code platforms first utilizes the browser's network module to analyze the page initialization phase, accurately identifying initial loading bottlenecks such as an excessive number of file requests within a preset time window or slow loading of a single large file, thus achieving precise localization of problems in the initial loading stage. Next, it combines the browser's network and performance modules to delve into the model processing process, discovering processing blockages caused by tasks exceeding set execution times or excessive device resource consumption, effectively revealing performance issues at the model-driven level. Subsequently, it continues to analyze the component loading and page rendering phases using the network and performance modules to identify rendering bottlenecks such as component loading redundancy, rendering timing discrepancies, or code logic blockages, effectively identifying front-end presentation layer problems. Finally, by comprehensively analyzing the bottlenecks in the above three stages, it ultimately identifies the key blockages affecting the overall page loading process, providing developers with a global optimization view, enabling them to prioritize and address the most critical performance issues. Therefore, the model-driven performance analysis method for low-code platforms provided in this application enables phased and multi-dimensional automated diagnosis, lowers the threshold for performance optimization, and allows even inexperienced developers to quickly take effective measures based on clear conclusions, thereby improving the development quality and user experience of low-code applications.

[0025] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0026] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings: Figure 1 A flowchart illustrating a performance analysis method for a model-driven low-code platform according to an embodiment of this application is shown schematically. Figure 2 This illustration schematically shows a performance analysis apparatus for a model-driven low-code platform according to an embodiment of this application; Figure 3 The diagram illustrates the internal structure of a computer device according to an embodiment of this application.

[0027] Explanation of reference numerals in the attached figures 200 - Performance analysis device for model-driven low-code platform; 201 - Initialization loading bottleneck determination module; 202 - Model processing bottleneck determination module; 203 - Rendering bottleneck determination module; 204 - Critical blocking point determination module; A01 - Processor; A02 - Network interface; A03 - Internal memory; A04 - Non-volatile storage medium; B01 - Operating system; B02 - Computer program. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0029] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0030] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0031] The acquisition, transmission, storage, use, and processing of data in this application comply with relevant national laws and regulations. Furthermore, it should be noted that existing industry solutions such as software, components, and models may be mentioned in the embodiments of this application. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0032] Figure 1 The illustration schematically depicts a flow diagram of a performance analysis method for a model-driven low-code platform according to an embodiment of this application. For example... Figure 1 As shown in one embodiment of this application, a performance analysis method for a model-driven low-code platform is provided. The performance analysis method for a model-driven low-code platform includes: S101: Analyzing the page initialization stage using the browser's network module to determine the initialization loading bottleneck; wherein, the initialization loading bottleneck includes file requests with a number exceeding a preset number within a preset time window or requests with a single request duration exceeding a preset duration; S102: Analyzing the model processing stage using the browser's network module and performance module to determine the model processing bottleneck; wherein, the model processing bottleneck includes tasks with execution duration exceeding a set duration or processing blockages caused by device resource consumption; S103: Analyzing the component loading and page rendering stages using the browser's network module and performance module to determine the rendering bottleneck; wherein, the rendering bottleneck includes: component loading redundancy, rendering timing not conforming to expectations, animation frame rendering time exceeding a preset time, or code logic blockages; S104: Based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck, performing comprehensive performance analysis to determine the key blockages in the overall page loading process.

[0033] Specifically, in this embodiment, the performance analysis method can be applied to a model-driven low-code application development platform. This platform allows developers to build complex web applications by dragging and dropping components and configuring model data. When a developer needs to perform performance diagnostics on a specific application page, they can trigger the performance analysis method of this application.

[0034] First, during the page initialization analysis, the browser's performance API is invoked to obtain detailed data on the network module. All loaded resources are automatically analyzed, and by counting the number of concurrent requests within a preset time window (e.g., 100 milliseconds), it is identified whether there are file requests exceeding a preset number within that window. Simultaneously, the loading time of each resource is compared to a preset duration (e.g., 1 second) to identify files whose individual request duration exceeds the preset duration. For example, too many file requests in a short period might cause requests to queue, or a core library file might be too large or have a slow server response, slowing down the entire page's startup speed. Once such bottlenecks are identified, they are marked as initialization loading bottlenecks.

[0035] Next, in the model processing phase analysis, data from the network and performance modules are combined. The low-code platform's core engine parses model data, constructs the component tree, and executes data binding logic. It monitors task execution on the main thread; if a task's execution time significantly exceeds the set time, or if abnormal peaks occur in CPU usage, memory usage, or other device resources, causing the main thread to be blocked, it is identified as a bottleneck in model processing, and the specific task type and resource usage are recorded.

[0036] Subsequently, in the analysis of the component loading and page rendering phases, in-depth tracking was further conducted using network and performance modules. This phase focuses on how the browser renders components into visual pixels. The analysis examines whether there is redundant component loading, such as loading components or their dependent resources that are not actually used on the page; whether there are anomalies in rendering timing that do not conform to expectations, such as critical rendering paths being blocked by non-critical resources; whether there are anomalies in animation frame rendering time exceeding the preset time, such as discontinuous animation playback and frame drops / stuttering; and whether there are code logic blockages, such as the browser being frozen and unresponsive due to time-consuming calculations or page operations performed during component loading or updating. These will all be identified and categorized as rendering bottlenecks.

[0037] Finally, in the comprehensive performance analysis phase, all bottleneck information identified in the first three phases is summarized and quantitatively evaluated. For example, each bottleneck is assigned a weight based on its specific impact on user wait time. A bottleneck that causes the page to be completely blank for the first few seconds will have a higher weight than a bottleneck that only affects a minor animation after the page has finished loading. Through weighted calculation and sorting, the key bottlenecks with the greatest impact on overall page loading performance can be filtered out from numerous bottlenecks and presented to developers in a visual report. The report clearly indicates the stage in which the bottleneck occurs, its specific type, the duration of its impact, and optimization suggestions.

[0038] In one possible implementation, the performance analysis process described above can be achieved by interpreting the graphical interface of the browser developer tools. During the page initialization phase, the graphical network module visually analyzes and identifies file requests exceeding a preset number within a preset time window, and files with individual request durations exceeding a preset duration, caused by the large size of the low-code platform's initialization files. During the model processing phase, the graphical timeline of the performance module, combined with network request details, analyzes the request, identification, and loading process of model data, and locates tasks whose execution time exceeds a set duration, causing main thread blocking. During the component loading and page rendering phases, the multi-dimensional views provided by the performance module are used for diagnosis: an image-based page loading process view identifies anomalies where rendering timing does not meet expectations; a network request view analyzes component loading details to discover component loading redundancy; a page animation rendering view identifies anomalies where animation frame rendering time exceeds a preset time; and a page task execution interval view identifies code logic blocking points causing lag. Finally, based on the various bottlenecks identified by the above graphical analysis, a comprehensive evaluation is conducted to determine the key blocking points affecting the overall page loading performance.

[0039] The performance analysis method for model-driven low-code platforms provided in this application can break down the complex loading process into three stages, and perform specialized analysis on the network requests, task execution, and rendering logic of each stage, thereby accurately locating the root cause of the problem. By comprehensively and quantitatively comparing the impact of all bottlenecks on overall performance, key blocking points can be identified, helping developers prioritize and address the most critical issues first. This transforms complex performance analysis into a simple diagnostic process, enabling developers to quickly locate and resolve problems based on clear conclusions without needing to be performance experts, effectively improving development quality and application experience.

[0040] In one embodiment, the rendering bottleneck includes code logic blocking points; determining the rendering bottleneck includes: acquiring page screenshots at different time intervals, visually displaying the rendering status of the page in different time intervals to locate the time interval of the code logic blocking point; and determining the code logic blocking point based on the time interval of the code logic blocking point.

[0041] In one specific implementation, to accurately pinpoint code logic bottlenecks, browser window screenshots are captured at a high frequency (e.g., every 50 milliseconds) during component loading and page rendering phases and saved in chronological order. These consecutive screenshots are then combined into a visual timeline interface, allowing developers to intuitively observe the rendering status of each frame during the page loading process, much like dragging a video progress bar. If a developer observes that the page freezes for a certain period (e.g., from 500 milliseconds to 800 milliseconds), it indicates that there is code logic blocking in that interval, meaning the browser's main thread has paused all rendering operations due to executing a time-consuming synchronous task. After determining the critical time interval, the detailed call stack recorded by the browser performance interface for that interval is immediately retrieved. By analyzing the function execution records in the call stack, it is possible to precisely trace which specific function (e.g., a component's lifecycle hook function) performed the time-consuming synchronous calculation or a large number of document object model operations, ultimately identifying the specific location and root cause of the bottleneck.

[0042] The performance analysis method for model-driven low-code platforms provided in this application can transform vague page lag issues into specific problems with a clear time frame. Developers can directly find the root cause of lag from massive amounts of data based on the time frame, providing a precise time range for subsequent code analysis and improving troubleshooting efficiency.

[0043] In one embodiment, determining the code logic blocking point based on the time interval of the code logic blocking point includes: analyzing the task execution interval and time consumption of the main thread based on the time interval of the code logic blocking point, and locating the specific execution function that causes the long task to be generated, so as to determine the code logic blocking point.

[0044] Specifically, in this embodiment, within the determined time interval of the code logic blocking point, the browser performance interface is further utilized to obtain detailed task execution records of the main thread within that interval. By analyzing these records, long tasks whose execution time exceeds a set time (e.g., 50 milliseconds) can be identified. For long tasks, their function call stacks are analyzed in depth. The call stack will display the call relationships between functions and their respective execution times in the form of a tree structure or flame graph. By comparing the execution times of each function, the specific execution function with the longest execution time can be located. This function is the root cause of the code logic blocking, thus ultimately determining the code logic blocking point.

[0045] The performance analysis method for model-driven low-code platforms provided in this application can pinpoint problems from a broad time range to specific execution functions. Developers no longer need to manually check large amounts of code; instead, they can directly identify the root cause of performance bottlenecks, making the repair work clear and improving the efficiency of debugging and optimization.

[0046] In one embodiment, the rendering bottleneck includes an anomaly where the animation frame rendering time exceeds a preset time; determining the rendering bottleneck includes: analyzing the rendering time of the page animation to determine the anomaly where the animation frame rendering time exceeds the preset time.

[0047] Specifically, in this embodiment, to determine an anomaly where the animation frame rendering time exceeds a preset time, the rendering loop of the page animation is accessed. The rendering timestamp of each frame is recorded using the animation frame rendering callback interface, and the time difference between consecutive frames is calculated to obtain the actual rendering time of each frame. The calculated single-frame rendering time is compared with the preset time, which is typically set based on the target frame rate, for example, 16.7 milliseconds for 60 frames per second. Frames whose rendering time exceeds the preset time are considered to have a rendering anomaly. Finally, a time series chart is generated from all collected frame time data. The chart will indicate the baseline corresponding to the target frame rate, and all rendering time peaks exceeding the baseline are the specific locations of the anomalies where the animation frame rendering time exceeds the preset time.

[0048] The performance analysis method for model-driven low-code platforms provided in this application can transform subjective perceptions of animation stuttering into objective, quantifiable frame rendering data. Developers can accurately identify which frame timed out, thus providing clear and specific targets for code optimization.

[0049] In one embodiment, the step of performing comprehensive performance analysis based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck to determine the key bottlenecks in the overall page loading process includes: constructing a performance dependency graph, which is used to characterize the dependency relationships between the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck; and based on the performance dependency graph, determining the loading time impact weights of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck, respectively, to determine the key bottlenecks in the overall page loading process.

[0050] Specifically, in this embodiment, the start and end timestamps of the three bottlenecks—initial loading, model processing, and rendering—are first collected. Using this time data, a performance dependency graph is constructed. In this graph, each bottleneck is represented as a node, and the dependencies between nodes are connected by directed edges. For example, if the start time of model processing is later than the end time of initial loading, an edge is drawn from the initial loading node to the model processing node. Based on the performance dependency graph, the comprehensive impact of each bottleneck on the overall page loading process is analyzed. This impact includes both its own execution time and its position and role in the entire dependency chain. By quantifying this comprehensive impact into an impact weight, the bottleneck with the highest weight can be identified, i.e., the key bottleneck in the overall page loading process.

[0051] The performance analysis method for model-driven low-code platforms provided in this application allows for a holistic understanding of performance issues, rather than viewing each component in isolation. By analyzing the dependencies between bottlenecks, the method can accurately identify the bottlenecks that have the greatest impact on the overall page load time. This enables developers to prioritize optimizations, focus their efforts on solving the most critical problems, and avoid wasting energy on secondary issues, thereby ensuring that optimization efforts bring the most significant performance improvements.

[0052] In one embodiment, constructing the performance dependency graph includes: taking file requests whose number of requests exceeds a preset number or whose single request duration exceeds a preset duration within a preset time window in the initialization loading bottleneck as the starting node of the graph; taking tasks or resource consumption blocking points in the model processing bottleneck whose execution time exceeds a set duration as intermediate processing nodes of the graph; taking component loading redundancy, rendering timing not conforming to expectations, animation frame rendering time exceeding a preset time, or code logic blocking points in the rendering bottleneck as downstream nodes of the graph; and establishing the dependency relationship between the starting node, intermediate processing node, and downstream node.

[0053] Specifically, in this embodiment, when constructing the performance dependency graph, the following nodes are first defined as the starting nodes of the graph: those file requests whose number of requests exceeds a preset number or whose individual request duration exceeds a preset duration within a preset time window, discovered during the initialization loading phase. These nodes mark the beginning of the entire loading process. Next, tasks or resource consumption bottlenecks identified during the model processing phase that exceed a set execution time are defined as intermediate processing nodes, which receive the initialized data and begin core computation. Finally, component loading redundancy, rendering timing discrepancies, animation frame rendering times exceeding preset times, or code logic bottlenecks detected during the rendering phase are defined as downstream nodes, representing the final manifestation of performance issues. After defining the nodes, directed connections are established from the starting node to the intermediate processing node and then to the downstream node based on the order of these nodes in the loading process, thus completely depicting the dependency chain between problems.

[0054] The performance analysis method for model-driven low-code platforms provided in this application can connect scattered performance issues into a clear causal chain. It clearly reveals that rendering problems are caused by upstream model processing or initialization loading issues. This allows developers to trace the chain upwards, accurately pinpointing the true source of the problem, rather than merely fixing surface symptoms, making optimization measures more thorough and effective.

[0055] In one embodiment, determining the loading time impact weights of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck based on the performance dependency graph to identify key blocking points in the overall page loading process includes: determining at least one critical path from the starting node to the downstream node and calculating the total time consumption of each critical path; obtaining the time consumption of each bottleneck node on each critical path; calculating the impact weight of each bottleneck node based on its time consumption and the total time consumption of the critical path it belongs to; and identifying the bottleneck node with the largest impact weight as the key blocking point.

[0056] Specifically, in this embodiment, in the constructed performance dependency graph, all complete paths from the starting node to the downstream node are identified, and the total time for each path is calculated. The path or paths with the longest total time are identified as critical paths. Next, the specific time of each bottleneck node on these critical paths is obtained. Then, the time of each bottleneck node is divided by the total time of its critical path to obtain a ratio, which is the influence weight of that node. Finally, by comparing the influence weights of all bottleneck nodes, the node with the largest weight value is identified as the critical bottleneck point in the entire loading process.

[0057] The performance analysis method for model-driven low-code platforms provided in this application can comprehensively consider the node's own time consumption and its position in critical processes, accurately pinpointing the bottlenecks that have the greatest impact on overall performance. Clear quantitative criteria are provided, allowing developers to clearly understand which issues should be prioritized for maximum performance improvement, avoiding wasted effort on secondary problems.

[0058] In one embodiment, the method further includes: constructing a causal graph, the causal graph being used to characterize the causal dependencies between model requests and data parsing constituting the model data processing stage, and / or between component loading and page rendering constituting the component loading and page rendering stage; locating the target link corresponding to the key blocking point in the causal graph; tracing upstream along the target link to locate the source event that triggered the key blocking point; and analyzing downstream along the target link to determine the subsequent rendering events blocked by the key blocking point.

[0059] In one embodiment, constructing the causal graph includes: associating a request to obtain a model file with a task to parse the file; associating a component referenced in the model file with a request to load the component's resources; and associating a component resource loading completion event with a page layout update or drawing event.

[0060] Specifically, in this embodiment, to deeply analyze the problem, a causal graph is first constructed. When constructing the causal graph, the request to obtain the model file is first associated with the subsequent file parsing task. Then, based on the content of the model file, the components referenced within it are associated with the requests to load the resources of these components. Finally, the event of the component resource loading completion is associated with the page layout update or rendering event it triggers. This graph details the causal chain of events, such as how model requests trigger data parsing during the model data processing stage, and how component loading triggers page rendering during the component loading and page rendering stages. After the graph is constructed, the specific link through the identified key bottleneck is located, i.e., the target link. Then, the target link is traced upstream to find the source event that initially triggered the entire chain. Simultaneously, the target link is analyzed downstream to identify subsequent rendering events that cannot be executed normally due to the bottleneck.

[0061] The performance analysis method for model-driven low-code platforms provided in this application can both trace back to find the root cause of the problem and analyze downwards to see the specific impact of the problem, thereby making the problem fix more thorough and targeted.

[0062] Please refer to Figure 2This application provides a performance analysis device 200 for a model-driven low-code platform, comprising: an initialization loading bottleneck determination module, used to analyze the page initialization phase using the browser's network module to determine the initialization loading bottleneck; wherein the initialization loading bottleneck includes file requests whose number of requests exceeds a preset number within a preset time window or requests whose duration exceeds a preset duration; a model processing bottleneck determination module, used to analyze the model processing phase using the browser's network module and performance module to determine the model processing bottleneck; wherein the model processing bottleneck includes tasks whose execution time exceeds a set duration or processing blockages caused by device resource consumption; a rendering bottleneck determination module, used to analyze the component loading and page rendering phases using the browser's network module and performance module to determine the rendering bottleneck; wherein the rendering bottleneck includes: component loading redundancy, rendering timing not conforming to expectations, animation frame rendering time exceeding a preset time, or code logic blockages; and a key blockage point determination module, used to perform comprehensive performance analysis based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck to determine the key blockage points in the overall page loading process.

[0063] In one embodiment, the rendering bottleneck includes code logic blocking points; determining the rendering bottleneck includes: acquiring page screenshots at different time intervals, visually displaying the rendering status of the page in different time intervals to locate the time interval of the code logic blocking point; and determining the code logic blocking point based on the time interval of the code logic blocking point.

[0064] In one embodiment, determining the code logic blocking point based on the time interval of the code logic blocking point includes: analyzing the task execution interval and time consumption of the main thread based on the time interval of the code logic blocking point, and locating the specific execution function that causes the long task to be generated, so as to determine the code logic blocking point.

[0065] In one embodiment, the rendering bottleneck includes an anomaly where the animation frame rendering time exceeds a preset time; determining the rendering bottleneck includes: analyzing the rendering time of the page animation to determine the anomaly where the animation frame rendering time exceeds the preset time.

[0066] In one embodiment, the step of performing comprehensive performance analysis based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck to determine the key bottlenecks in the overall page loading process includes: constructing a performance dependency graph, which is used to characterize the dependency relationships between the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck; and based on the performance dependency graph, determining the loading time impact weights of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck, respectively, to determine the key bottlenecks in the overall page loading process.

[0067] In one embodiment, constructing the performance dependency graph includes: taking file requests whose number of requests exceeds a preset number or whose single request duration exceeds a preset duration within a preset time window in the initialization loading bottleneck as the starting node of the graph; taking tasks or resource consumption blocking points in the model processing bottleneck whose execution time exceeds a set duration as intermediate processing nodes of the graph; taking component loading redundancy, rendering timing not conforming to expectations, animation frame rendering time exceeding a preset time, or code logic blocking points in the rendering bottleneck as downstream nodes of the graph; and establishing the dependency relationship between the starting node, intermediate processing node, and downstream node.

[0068] In one embodiment, determining the loading time impact weights of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck based on the performance dependency graph to identify key blocking points in the overall page loading process includes: determining at least one critical path from the starting node to the downstream node and calculating the total time consumption of each critical path; obtaining the time consumption of each bottleneck node on each critical path; calculating the impact weight of each bottleneck node based on its time consumption and the total time consumption of the critical path it belongs to; and identifying the bottleneck node with the largest impact weight as the key blocking point.

[0069] The performance analysis device of the model-driven low-code platform includes a processor and a memory. The initialization loading bottleneck determination module, the model processing bottleneck determination module, the rendering bottleneck determination module, and the key blocking point determination module are all stored as program units in the memory. The processor executes the above program modules stored in the memory to implement the corresponding functions.

[0070] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and performance analysis methods for model-driven low-code platforms can be implemented by adjusting kernel parameters.

[0071] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0072] This application provides a processor configured to execute the performance analysis method for a model-driven low-code platform described above.

[0073] This application provides a machine-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the performance analysis method for a model-driven low-code platform described above.

[0074] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 3 As shown. Figure 3 This schematic diagram illustrates the internal structure of a computer device according to an embodiment of the present application. The computer device includes a processor A01, a network interface A02, a memory (not shown), and a database (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes internal memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01, a computer program B02, and a database (not shown). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A04. The network interface A02 is used for communication with external terminals via a network connection. When the computer program B02 is executed by the processor A01, it implements a performance analysis method for a model-driven low-code platform.

[0075] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0076] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: Analyzing the page initialization phase using the browser's network module to determine initialization loading bottlenecks; wherein, the initialization loading bottlenecks include file requests exceeding a preset number of requests within a preset time window or requests with a single request duration exceeding a preset duration; Analyzing the model processing phase using the browser's network and performance modules to determine model processing bottlenecks; wherein, the model processing bottlenecks include tasks with execution times exceeding a set duration or processing blockages caused by device resource consumption; Analyzing the component loading and page rendering phases using the browser's network and performance modules to determine rendering bottlenecks; wherein, the rendering bottlenecks include: component loading redundancy, rendering timing discrepancies, animation frame rendering times exceeding a preset time, or code logic blockages; Based on the initialization loading bottlenecks, the model processing bottlenecks, and the rendering bottlenecks, performing a comprehensive performance analysis to determine key blockages in the overall page loading process.

[0077] In one embodiment, the rendering bottleneck includes code logic blocking points; determining the rendering bottleneck includes: acquiring page screenshots at different time intervals, visually displaying the rendering status of the page in different time intervals to locate the time interval of the code logic blocking point; and determining the code logic blocking point based on the time interval of the code logic blocking point.

[0078] In one embodiment, determining the code logic blocking point based on the time interval of the code logic blocking point includes: analyzing the task execution interval and time consumption of the main thread based on the time interval of the code logic blocking point, and locating the specific execution function that causes the long task to be generated, so as to determine the code logic blocking point.

[0079] In one embodiment, the rendering bottleneck includes an anomaly where the animation frame rendering time exceeds a preset time; determining the rendering bottleneck includes: analyzing the rendering time of the page animation to determine the anomaly where the animation frame rendering time exceeds the preset time.

[0080] In one embodiment, the step of performing comprehensive performance analysis based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck to determine the key bottlenecks in the overall page loading process includes: constructing a performance dependency graph, which is used to characterize the dependency relationships between the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck; and based on the performance dependency graph, determining the loading time impact weights of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck, respectively, to determine the key bottlenecks in the overall page loading process.

[0081] In one embodiment, constructing the performance dependency graph includes: taking file requests whose number of requests exceeds a preset number or whose single request duration exceeds a preset duration within a preset time window in the initialization loading bottleneck as the starting node of the graph; taking tasks or resource consumption blocking points in the model processing bottleneck whose execution time exceeds a set duration as intermediate processing nodes of the graph; taking component loading redundancy, rendering timing not conforming to expectations, animation frame rendering time exceeding a preset time, or code logic blocking points in the rendering bottleneck as downstream nodes of the graph; and establishing the dependency relationship between the starting node, intermediate processing node, and downstream node.

[0082] In one embodiment, determining the loading time impact weights of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck based on the performance dependency graph to identify key blocking points in the overall page loading process includes: determining at least one critical path from the starting node to the downstream node and calculating the total time consumption of each critical path; obtaining the time consumption of each bottleneck node on each critical path; calculating the impact weight of each bottleneck node based on its time consumption and the total time consumption of the critical path it belongs to; and identifying the bottleneck node with the largest impact weight as the key blocking point.

[0083] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0084] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0085] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0086] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0087] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0088] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0089] Computer-readable media include both permanent and non-permanent, removable and non-removable media, which can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0090] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0091] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A performance analysis method for a model-driven low-code platform, characterized in that, The performance analysis method for the model-driven low-code platform includes: The browser's network module is used to analyze the page initialization phase to identify initial loading bottlenecks; wherein, the initial loading bottlenecks include file requests whose number of requests exceeds a preset number within a preset time window or requests whose single request duration exceeds a preset duration. By utilizing the browser's network and performance modules, the model processing stage is analyzed to identify model processing bottlenecks; wherein, the model processing bottlenecks include processing blockages caused by tasks that take longer than a set time or by device resource consumption; By utilizing the browser's network and performance modules, analyze the component loading and page rendering stages to identify rendering bottlenecks. These bottlenecks include: redundant component loading, exceptions where the rendering sequence does not meet expectations, exceptions where animation frame rendering time exceeds a preset time, or code logic blocking points. Based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck, a comprehensive performance analysis is conducted to identify the key blocking points in the overall page loading process.

2. The performance analysis method for a model-driven low-code platform according to claim 1, characterized in that, The rendering bottlenecks include code logic blocking points; The determination of rendering bottlenecks includes: Capture screenshots of the page at different time intervals to visualize the rendering status of the page in different time intervals, so as to locate the time interval of the code logic blockage point; Determine the code logic blocking points based on the time interval of the blocking points.

3. The performance analysis method for a model-driven low-code platform according to claim 2, characterized in that, The determination of code logic blocking points based on the time interval of the code logic blocking point includes: Based on the time interval of the code logic blocking point, analyze the task execution interval and time of the main thread, and locate the specific execution function that causes the long task to occur, so as to determine the code logic blocking point.

4. The performance analysis method for a model-driven low-code platform according to claim 1, characterized in that, The rendering bottlenecks include anomalies where animation frame rendering time exceeds a preset time; The determination of rendering bottlenecks includes: Analyze the rendering time of page animations to identify anomalies where animation frame rendering times exceed preset times.

5. The performance analysis method for a model-driven low-code platform according to claim 1, characterized in that, Based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck, a comprehensive performance analysis is performed to identify the key blocking points in the overall page loading process, including: Construct a performance dependency graph, which is used to characterize the dependency relationship between the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck; Based on the performance dependency graph, the impact weights of the loading time of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck are determined respectively, so as to identify the key blocking points in the overall page loading process.

6. The performance analysis method for a model-driven low-code platform according to claim 5, characterized in that, The construction of the performance dependency graph includes: The file requests with a number of requests exceeding a preset number or the single request duration exceeding a preset duration within the preset time window in the initial loading bottleneck are taken as the starting nodes of the graph. Tasks or resource consumption bottlenecks in the model that have an execution time exceeding a set time are used as intermediate processing nodes in the graph. Component loading redundancy, rendering timing not in accordance with expectations, animation frame rendering time exceeding the preset time, or code logic blocking points in the rendering bottleneck are regarded as downstream nodes of the graph. Establish the dependency relationships between the starting node, intermediate processing node, and downstream node.

7. The performance analysis method for a model-driven low-code platform according to claim 6, characterized in that, Based on the performance dependency graph, the impact weights of the loading time of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck are determined respectively, in order to identify the key blocking points in the overall page loading process, including: Determine at least one critical path from the starting node to the downstream node, and calculate the total time for each critical path; Obtain the time consumed by each bottleneck node on each critical path; Calculate the impact weight of each bottleneck node based on its time consumption and the total time consumption of the critical path it belongs to. The bottleneck node with the greatest impact is identified as the critical blockage point.

8. A performance analysis device for a model-driven low-code platform, characterized in that, The performance analysis device for the model-driven low-code platform includes: The initialization loading bottleneck determination module is used to analyze the page initialization phase using the browser's network module to determine the initialization loading bottleneck; wherein, the initialization loading bottleneck includes file requests whose number of requests exceeds a preset number within a preset time window or requests whose single request duration exceeds a preset duration. The model processing bottleneck identification module is used to analyze the model processing stage and identify model processing bottlenecks by utilizing the browser's network module and performance module; wherein, the model processing bottlenecks include processing blockages caused by tasks that take longer than a set time or by device resource consumption; The rendering bottleneck identification module is used to analyze the component loading and page rendering stages using the browser's network module and performance module to identify rendering bottlenecks. The rendering bottlenecks include: redundant component loading, abnormal rendering timing, abnormal animation frame rendering time exceeding the preset time, or code logic blocking points. The critical bottleneck identification module is used to perform comprehensive performance analysis based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck to identify the critical bottlenecks in the overall page loading process.

9. The performance analysis device for a model-driven low-code platform according to claim 8, characterized in that, The rendering bottlenecks include code logic blocking points; The determination of rendering bottlenecks includes: Capture screenshots of the page at different time intervals to visualize the rendering status of the page in different time intervals, so as to locate the time interval of the code logic blockage point; Determine the code logic blocking points based on the time interval of the blocking points.

10. The performance analysis device for a model-driven low-code platform according to claim 9, characterized in that, The determination of code logic blocking points based on the time interval of the code logic blocking point includes: Based on the time interval of the code logic blocking point, analyze the task execution interval and time of the main thread, and locate the specific execution function that causes the long task to occur, so as to determine the code logic blocking point.

11. The performance analysis device for a model-driven low-code platform according to claim 8, characterized in that, The rendering bottlenecks include anomalies where animation frame rendering time exceeds a preset time; The determination of rendering bottlenecks includes: Analyze the rendering time of page animations to identify anomalies where animation frame rendering times exceed preset times.

12. The performance analysis device for a model-driven low-code platform according to claim 8, characterized in that, Based on the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck, a comprehensive performance analysis is performed to identify the key blocking points in the overall page loading process, including: Construct a performance dependency graph, which is used to characterize the dependency relationship between the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck; Based on the performance dependency graph, the impact weights of the loading time of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck are determined respectively, so as to identify the key blocking points in the overall page loading process.

13. The performance analysis device for a model-driven low-code platform according to claim 12, characterized in that, The construction of the performance dependency graph includes: The file requests with a number of requests exceeding a preset number or the single request duration exceeding a preset duration within the preset time window in the initial loading bottleneck are taken as the starting nodes of the graph. Tasks or resource consumption bottlenecks in the model that have an execution time exceeding a set time are used as intermediate processing nodes in the graph. Component loading redundancy, rendering timing not in accordance with expectations, animation frame rendering time exceeding the preset time, or code logic blocking points in the rendering bottleneck are regarded as downstream nodes of the graph. Establish the dependency relationships between the starting node, intermediate processing node, and downstream node.

14. The performance analysis device for a model-driven low-code platform according to claim 13, characterized in that, Based on the performance dependency graph, the impact weights of the loading time of the initialization loading bottleneck, the model processing bottleneck, and the rendering bottleneck are determined respectively, in order to identify the key blocking points in the overall page loading process, including: Determine at least one critical path from the starting node to the downstream node, and calculate the total time for each critical path; Obtain the time consumed by each bottleneck node on each critical path; Calculate the impact weight of each bottleneck node based on its time consumption and the total time consumption of the critical path it belongs to. The bottleneck node with the greatest impact is identified as the critical blockage point.

15. A processor, characterized in that, The method is configured to perform performance analysis on a model-driven low-code platform as described in any one of claims 1 to 7.

16. A machine-readable storage medium storing instructions thereon, characterized in that, When executed by a processor, this instruction causes the processor to be configured to perform the performance analysis method for the model-driven low-code platform as described in any one of claims 1 to 7.

17. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the performance analysis method for the model-driven low-code platform as described in any one of claims 1 to 7.

Images