Automatic performance monitoring adjustment device for browser-side visual development tools

Abstract

The automatic performance monitoring adjustment device of browser-side visual development tool relates to the field of information technology, and the device is composed of a logic engine, an intermediate data set and a drawing engine; the drawing engine is composed of a drawing scheduling module, a drawing execution module and a data acquisition engine; the drawing scheduling module is composed of a statistics center module, a performance monitoring module and a state monitoring module; the optimization strategy adopted by the device can quickly take effect without technical implementation details, greatly improving the efficiency, and the more the page opening times, the better the optimization effect, so that the problem of too great carrier heterogeneity of page display is solved.

Description

Technical Field

[0001] This invention relates to the field of information technology. Background Technology

[0002] Drag-and-drop data visualization tools in browsers can lower the professional barrier to data visualization application development, allowing even those without web development knowledge to participate in the development of such applications. However, in practice, users often report that visualizations created with these tools perform worse than those developed using web project development models. Therefore, performance optimization is often a long and arduous task for these tools.

[0003] Since tools rely on browsers for display, their performance is closely related to the performance of the computers running those browsers. These computers are user computers, some with good performance and others with poor performance. Therefore, performance optimization by developers working in isolation often fails to cover all issues. Expanding the testing scope for performance optimization during development is often limited by resources, costs, and time. Furthermore, given the significant differences between user computers, even if we had the resources to expand the scope for performance optimization testing and tuning, it's difficult to find a standard that guarantees complete coverage.

[0004] Many tool users hope that tools can provide automatic performance optimization methods. This scenario often occurs when visualization applications are used for a long time, and the page will slow down as the running time increases. If the page slows down at this time, we usually force refresh the page, and then the developers explain that the browser is consuming more resources. Therefore, some users have suggested that the program can detect excessive browser resource consumption and automatically refresh the page, so as to release useless resources.

[0005] Visualization tools are productivity tools, primarily improving the work patterns of their users. However, whether the final product or service provided by the tool has the same quality as that developed using traditional R&D methods is a crucial indicator for user evaluation. Therefore, those using the tool's services often compare pages created by the tool team with those created through traditional R&D. In contrast, performance optimization issues in traditional R&D pages often receive effective responses and optimization actions, while performance optimization in tools is often difficult to achieve. Often, even when slow page response is detected, a professional explanation is hard to come by, let alone practical optimization methods. This is because tools often employ fixed logical patterns to reduce coding and development work, making program modifications within these patterns extremely difficult. Therefore, are there automated performance optimization methods that can be implemented without modifying the tool's underlying logic code?

[0006] The issues that need to be addressed are performance problems of pages created using browser-based drag-and-drop data visualization tools, specifically: 1. Slow page loading; 2. Noticeable page lag, mainly due to the page's inability to respond promptly to mouse interactions; 3. Unsmooth animations of some components on the page, with interactive animations being unresponsive; 4. Page crashes or becomes unusable.

[0007] Page load speed primarily refers to the time from when a user initiates a page visit to when the page is fully rendered. Web applications rely on browsers to retrieve data from the server via HTTP requests. Once the data arrives in the browser, it uses that data to create the corresponding graphics. Therefore, the browser must obtain complete and accurate server data before rendering. Generally, HTTP requests, which rely on network transmission, are relatively inefficient, resulting in a noticeable time lag in data retrieval. Thus, network transmission efficiency affects page load speed. If the server data is already ready, but the browser is rendering highly complex graphics, such as 3D graphics, or very large graphics, the browser's rendering efficiency will also decrease significantly, further impacting page load speed. The browser rendering phase primarily relies on the capabilities of the computer's CPU, memory, and GPU.

[0008] Page display smoothness can manifest in two scenarios: interactive actions and animations. Animations often exhibit noticeable stuttering or lag. Aside from network requests, changes in on-page graphics require significant processing power from the computer's CPU, memory, and GPU. Animation is essentially a continuous display of images. The human eye experiences visual persistence; if more than 24 images are displayed consecutively per second, the images appear to move, mimicking real-world actions. However, fewer than 24 images per second result in noticeable stuttering. Therefore, browser animation essentially involves rendering more than 24 images per second, making it an extremely resource-intensive operation.

[0009] This only considers crashes and unavailability caused by the page's own programming. These problems are often caused by the page itself overloading its CPU, memory, and GPU. Solving page loading performance issues requires addressing the page's network requests, CPU usage, memory usage, and GPU usage.

[0010] When a browser draws graphics, it needs to access the computer's system resources. However, the computer isn't constantly performing drawing operations. The network request mentioned above is a similar example. We consider network latency as part of the drawing process, so network latency affects drawing efficiency. In reality, the browser doesn't perform the corresponding drawing operations until the network communication is complete. Even when accessing CPU, memory, and GPU resources, drawing operations aren't performed all the time. This is the browser's single-threaded mode, which I will explain in detail below:

[0011] Early browsers, such as those from the era of the browser wars between Microsoft and Netscape, and before the advent of Google's Chrome browser, operated on a single-process, multi-threaded model. The browser software itself was a single process, and each webpage opened by the browser was a separate thread. Therefore, in this era, if one webpage froze, the entire browser would freeze. After Chrome emerged, all browsers adopted a multi-process model. Each tab of a webpage is a separate process, but the webpages within each tab still execute their program in a separate thread. We can abstract the browser's program into two main categories: programs that execute computational logic and programs that render the page. Both of these logics execute on a single thread. If the page thread is executing logic, subsequent page rendering programs must wait. If the logic takes too long to execute, the rendering wait time will also increase. If this waiting time becomes perceptible to the user, then the page may experience lag or stuttering. Despite the many years of browser development, the single-threaded mode has remained unchanged, indicating that single-threading is still the optimal browser execution mode. Therefore, it is certainly not advisable to arbitrarily break the single-threaded mode and make the computation and rendering logic run in parallel. However, if we can make some computational logic tasks that significantly affect page loading efficiency run asynchronously or in parallel with page rendering, it will greatly help improve the browser's display effect.

[0012] Network request performance issues. Network transmission efficiency is beyond the browser's control. Modern web applications primarily use Ajax technology, i.e., asynchronous HTTP requests. Asynchronous HTTP requests do not block the main page thread. After receiving the HTTP result, the processing result and callback function are added to the browser's main thread queue for execution. Network requests using Ajax technology and the browser's main thread execute asynchronously in parallel. Therefore, the execution of HTTP requests does not block page rendering. Different Ajax requests can be processed in parallel through this asynchronous mechanism, resulting in high execution efficiency. However, there is one scenario where network requests can become a performance issue affecting rendering: periodically retrieving data from the server. When data is retrieved from the server every 2 seconds, the browser renders the graphics. If the graphics are complex or numerous, the page will noticeably slow down as the timer increases. Initially, 2 seconds may be sufficient to complete the entire process, but gradually it becomes difficult, and eventually, it may not be able to complete the entire process within 2 seconds. Sometimes, the page may even crash due to this. Such scenarios are very common in visualization applications. The main reason for this effect is that the system resources called by the browser are not released in a timely manner. Here, we mainly analyze this performance issue from the perspective of CPU and memory. Any program running on a computer needs to use hardware resources such as the computer's CPU and memory. If the drawing interval is very short, the drawing operation will occupy a lot of CPU time, which will lead to a very high CPU utilization. As mentioned above, the browser is single-threaded. If a certain drawing operation occupies a lot of CPU time, it will inevitably reduce the execution time of other programs. Over time, the number of programs waiting to be executed in the browser's call stack will increase, which will compete with our periodic drawing task for CPU time. The final result is that the periodic drawing task is also slowed down. Similarly, the running memory of the program is indispensable. The browser's programming environment uses a periodic garbage collection mechanism to release invalid memory. When running periodic drawing operations, we can find through performance tools that the browser's memory usage is constantly increasing over time. If the browser's memory usage increases, the garbage collection mechanism will significantly slow down the browser's rendering. At the same time, excessive browser memory usage will also affect the execution efficiency of subsequent programs. Therefore, it's evident that in such scenarios, CPU and memory performance will gradually decrease over time, eventually leading to extremely high system resource usage and directly impacting normal browser operation. Theoretically, increasing the time interval of periodic tasks can effectively solve these problems; generally, a time interval on the order of minutes significantly reduces these issues.However, in specific business scenarios, time intervals often have specific business implications. We set shorter time intervals to reflect the real-time nature of the data or to present it to users as quickly as possible to help them resolve issues.

[0013] While using AJAX to execute HTTP requests doesn't interfere with the browser's main thread, the execution of HTTP requests can be affected by the main thread's efficiency under periodic requests. Browser timers like `setTimeout` and `setInterval` allow us to set a time interval, but this interval is often inaccurate in practice. For example, if we set a timer to execute after 2 seconds, and other programs complete within that 2-second wait, the interval might be guaranteed to be 2 seconds. However, in reality, many times the program execution exceeds 2 seconds, causing the execution interval to exceed 2 seconds. In other words, browser timers cannot guarantee that programs will run at the correct time. Therefore, in scenarios where data is periodically retrieved from the server, the main thread's slowdown due to insufficient computer resources is further exacerbated by the browser's single-threaded mode, making timer execution even more inaccurate. This is why network requests cannot be guaranteed to execute within the correct time period.

[0014] Browser graphics rendering issues arise because browser drawing operations require the coordinated efforts of the CPU, memory, and GPU. Graphics rendering itself can be divided into two processes: logical drawing and screen rendering. When drawing geometric shapes on a computer, numerous geometric principles are used, and these principles are calculated by the CPU and memory. The results calculated by the CPU then need to be delivered to the GPU to be converted into pixels on the screen. Compared to the GPU, the CPU has greater computing power, but CPUs are often fewer in number. While the GPU's computing power is relatively lower, its large number of cores allows it to perform large-scale parallel computing, which is well-suited for graphics rendering. If the GPU needs to draw a large number of complex pixels on the screen, it consumes significant GPU resources. If the GPU cannot quickly render the graphics to the screen, the associated CPU and memory resources cannot be released quickly, resulting in stuttering and lag in the graphics display. In the browser's programming environment, this prolonged rendering operation can block the browser's main thread from executing subsequent tasks. Furthermore, the significant differences in GPU performance between personal computers lead to substantial variations in the perceived performance of the same webpage for different users. If a browser needs to render graphics that are very demanding on the graphics card, some computers may not be able to complete the rendering at all, causing the browser to crash. Others may be able to render, but the rendering process will consume CPU, memory, and GPU for a long time, eventually causing browser resource overload and resulting in page lag.

[0015] Browser animation technology essentially involves continuously redrawing graphics at extremely short intervals. Human visual persistence allows for the display of 24 images consecutively per second. This necessitates a redraw every 40 milliseconds. Modern LCD monitors have a refresh rate of 60 Hz, meaning a redraw occurs approximately every 16.66 milliseconds. Theoretically, more redraws per second result in smoother visuals. Therefore, based on the data above, if page redraws exceed 40 milliseconds, stuttering and unresponsive animations will occur. Thus, executing complex animations for extended periods in a browser consumes more resources than redrawing in scenarios involving periodic data retrieval from the server. Consequently, performance degradation is more likely to occur with resource-intensive animations.

[0016] Based on the above analysis, the automatic performance monitoring and adjustment device of browser-side visual development tools mainly addresses the performance degradation caused by developing pages using visual development tools in the following ways:

[0017] The solution to network requests is that asynchronous network requests themselves have a limited impact on page rendering. However, the single-threaded model of the page can, in turn, affect the execution of network requests. This is mainly because initiating asynchronous network requests and processing the response results are completed by the main thread of the page. In scenarios where data is periodically retrieved from the server, the interval between sending network requests will become longer and longer. Ensuring that asynchronous network requests can still be executed at the correct time intervals under high browser load is a way to improve performance.

[0018] Memory optimization methods: Browsers have memory limits for pages. After running for a long time, resource consumption accumulates to a certain level. Refreshing the page or even restarting the browser is a necessary way to speed up page performance. Automating this process will be more effective.

[0019] In the browser's programming environment, programming languages ​​cannot directly obtain CPU and GPU performance parameters. Therefore, we need to estimate CPU and GPU performance through methods. In the computer field, a program consists of two parts: computation and data. Data is mainly stored in memory, while computation is performed by the CPU and GPU. The efficiency of computation is mainly measured by speed. We introduce the metric FPS (Frames Per Second), a definition in the graphics field, which refers to the number of frames transmitted per second. In simpler terms, it refers to the number of frames in an animation or video. FPS measures the amount of information used to store and display dynamic video. The higher the frame rate, the smoother the displayed motion. By monitoring and analyzing FPS data, we can obtain the browser's display performance metrics.

[0020] FPS allows us to estimate computational power. When developing charts, we can mark the technologies used in the charts, especially those drawn using WebGL technology. This allows us to group components by technology. If a component heavily relies on the GPU, we can accelerate the drawing operation by adjusting the drawing strategy or prevent it from blocking the drawing efficiency of other general charts.

[0021] Existing technology used

[0022] Timers. This refers to the `setTimeout` and `setInterval` techniques. `setTimeout` specifies the time interval after which a function will be executed, while `setInterval` specifies the interval after which a function will be executed. They also have two corresponding undefined operations: `clearTimeout` and `clearInterval`.

[0023] RequestAnimationFrame. This is a request-animation-frame technique, also a timer. Like setTimeout, it executes a function at regular intervals. However, this technique doesn't require setting the interval; its interval is determined by the computer's refresh rate. If the computer's FPS is 60 Hz, it will execute every 16.66 milliseconds. There's also a method to cancel the timer. Browser programming environments don't have direct APIs for calculating FPS, so we use request-animation-frames to calculate it. The purpose of request-animation-frames is to enable efficient animation on web pages.

[0024] The Performance Timeline API, also known as the Timing API, is a set of performance APIs provided by the HTML5 specification for measuring browser performance. Its primary performance metric is the difference between the start and end times. This API retrieves information about the page's memory usage.

[0025] Tools for precise time calculation include `performance.now()`, which can calculate to the microsecond, while browser time functions are only accurate to milliseconds. Therefore, a microsecond timer is far more accurate. Performance includes a default Navigation Timing API, which calculates page loading efficiency from the time the browser address is entered until the page loads successfully. Performance also has a Resource Timing API, which calculates the loading efficiency of various resources, including CSS, JavaScript, images, audio, and AJAX requests. Finally, there's a User Timing API, which allows programmers to define a start time to calculate code execution efficiency.

[0026] The Page Visibility API. A browser can open multiple pages, but typically only one page is active at a time. Furthermore, when the browser is minimized, the page is inactive. In an inactive browser, RequestAnimationFrames stop running, but timers continue. If we use RequestAnimationFrames for animations, the animation pauses in inactive mode, while animations using timers continue. In scenarios where data is periodically retrieved from the server, AJAX requests based on timers are constantly sending and receiving data in inactive mode. If graphics use RequestAnimationFrames, the drawing is not synchronized. Therefore, various unexpected problems can occur when the page is reactivated. The Page Visibility API can monitor whether a page is displayed or not. We can use its `visibilitychange` event to monitor and handle such scene transitions.

[0027] Web Workers are worker threads. The HTML5 standard provides a worker thread mechanism, where the browser can allocate a completely independent second-level sub-environment outside the original page environment. This sub-environment cannot interoperate with APIs that rely on single-threaded interaction, but it can execute code in parallel with the parent environment.

[0028] The browser's UI thread is the browser's main thread. Threads are divided into UI threads and worker threads. The UI thread has a window, and the window creates its own message queue. This message queue is the biggest difference between UI threads and worker threads. Therefore, threads with a user interface are generally called UI threads, while those without a user interface are called worker threads. Because UI threads have a user interface, the system maintains a message queue for them, while worker threads do not.

[0029] The UI thread, also known as the interface thread, can respond to specific messages from the operating system, including interface messages, mouse and keyboard messages, and custom messages. It is implemented by adding a message loop to the ordinary worker thread. The message loop continuously obtains messages dispatched by the operating system or other threads, and then finds the corresponding message handling object based on the message. If there are no messages to process temporarily, the thread waits and yields the CPU time slice, thus making the thread appear to be always online until a specific exit message terminates the thread.

[0030] Worker threads are used to avoid interfering with UI thread operations and causing UI blocking due to long-running tasks, thus improving user experience. A worker thread is created to handle complex tasks. Once a task is completed, it can exit immediately or continue waiting for new tasks, depending on the specific needs. A worker thread that doesn't exit after completing a task but remains in a waiting state is essentially not much different from the UI thread. A worker thread can also implement its own task queue to continuously acquire tasks and achieve the same effect as the UI thread.

[0031] AJAX uses front-end technology to send an asynchronous request to the server. The original request required refreshing the entire page after the request, but with AJAX, only a part of the page needs to be refreshed. Summary of the Invention

[0032] In view of the shortcomings of the prior art, the automatic performance monitoring and adjustment device of the browser-side visual development tool provided by the present invention consists of a logic engine, an intermediate dataset and a drawing engine; the drawing engine consists of a drawing scheduling module, a drawing execution module and a data retrieval engine; the drawing scheduling module consists of a statistics center module, a performance monitoring module and a status monitoring module;

[0033] The logic engine constructs worker threads responsible for executing AJAX requests and performing logical operations in drawing. It assigns a source identifier to each independent AJAX request and each logical operation in drawing. When the data returned by an AJAX request requires further processing, the calculation is performed in the logic engine, and the result, with the source identifier, is sent to the intermediate dataset. When the data returned by an AJAX request involves purely logical data processing, the calculation is performed in the logic engine, and the result, with the source identifier, is sent to the intermediate dataset. When the logical operation in drawing is completed, the result, with the source identifier and the drawing method to be used next, is sent to the intermediate dataset. The logic engine includes a timer, and each page's timer has a unique ID.

[0034] The intermediate dataset is an array built on the UI thread. The larger the index, the newer the data; the smaller the index, the older the data. Each element in the intermediate dataset has a unique identifier for its logical source, used to identify whether the data comes from the same processing logic. In addition to storing the data needed for drawing, the intermediate dataset also stores context information, which is metadata indicating where the data comes from and which drawing method should be used for drawing. The context information ensures the logical consistency of the data. The intermediate dataset has a flag that represents whether it is locked or unlocked, called the lock flag. When the logic engine writes data to the intermediate dataset, it first reads the lock flag. When the intermediate dataset is locked, the logic engine does not write data to it, but starts a timer. After the timer completes its interval, it reads the lock flag again. Only when the lock flag is unlocked does the logic engine complete the operation of writing data to the intermediate dataset.

[0035] The drawing execution module records the drawing functions, and each drawing function corresponds to a drawing method. The metadata in the drawing data stored in the intermediate dataset contains the specific drawing method that each data needs to use, which corresponds to the number of the drawing function in the drawing execution module.

[0036] The data retrieval engine retrieves data from the intermediate dataset. When there are no graphics to draw on the page, the data retrieval engine performs data retrieval operations from the intermediate dataset. When the data retrieval engine finds no data in the intermediate dataset, it polls the intermediate dataset at regular intervals. This polling period is the time interval between each screen refresh. At a computer maintaining a 60Hz refresh rate, the polling period is every 16 milliseconds. When the data retrieval engine retrieves data from the intermediate dataset, it sets a lock flag to prevent new data from being entered into the intermediate dataset. At this point, the data retrieval engine performs a deep copy. The data retrieval engine first transmits the data from the intermediate dataset to the drawing scheduling module, then sets the data in the intermediate dataset to null and unlocks it. Deep copying ensures that the data used by the drawing scheduling module is different from the data in the intermediate dataset, preventing information contamination. Furthermore, a deep copy without business logic allows the intermediate dataset's lock flag to be released as quickly as possible, avoiding prolonged or excessive polling operations. After transmitting the data to the drawing scheduling module, the data retrieval engine enters a sleep state until the drawing scheduling module sends a start command, at which point the engine restarts to retrieve data.

[0037] The function of the drawing scheduling module is to schedule the drawing of page graphics;

[0038] The performance monitoring module comprises two monitoring threads: one for page performance monitoring and the other for chart rendering performance monitoring. Page performance monitoring tracks the performance of each page refresh, including two metrics: the refresh interval and memory consumption per refresh. The monitored data is transmitted to a statistics center module in another worker thread for analysis and statistics. The page performance monitoring module transmits data to the statistics center module every second, which then calculates the page's FPS and memory consumption. Chart rendering performance monitoring tracks the time taken to render each chart during tool development, transmitting the results to the statistics center module after each chart is rendered. The performance monitoring module records the FPS and memory consumption for each page, as well as the rendering time for each chart, within the statistics center module.

[0039] The statistics center module categorizes charts based on their plotting time: Category 1: Charts completed within a single frame. This is defined as charts where the plotting time observed in each frame matches the chart's execution time. Category 2: Charts requiring multiple frames to plot. This is defined as charts whose execution time spans multiple frames. Category 3: Resource-intensive charts. This is defined as charts where the FPS during plotting is below 30 Hz, or where memory usage exceeds 50% of available memory during plotting. Category 4: Charts that cannot run properly on a computer. This is defined as charts where a single frame execution time exceeds 3 seconds, and memory consumption consistently exceeds 50% during execution.

[0040] The status monitoring module is mainly used to monitor whether the page is active. When it finds that the page is inactive, the status monitoring module will destroy the timer of the inactive page, thus avoiding invalid timed data retrieval operations.

[0041] When the page is active, the drawing scheduling module reads the data from the statistics center module, prioritizes the drawing of the first and second types of charts, releases computer computing resources and refreshes the page when drawing the third type of chart, and gives a prompt that the local configuration cannot draw the fourth type of chart.

[0042] Beneficial effects

[0043] The optimization strategy adopted in this invention is a solution that can achieve rapid results without relying on technical implementation details. It transfers some experiential skills to the tool, which often requires on-site guidance from professionals. This greatly improves efficiency and provides knowledge reference for those who want to delve into the details of optimization. Furthermore, the more times a page is opened, the better the optimization effect, thus solving the problem of excessive heterogeneity in page display formats. Attached Figure Description

[0044] Figure 1 This is a system structure diagram of the present invention. Detailed Implementation

[0045] See Figure 1 The automatic performance monitoring and adjustment device for the browser-side visual development tool provided by this invention consists of a logic engine 1, an intermediate dataset 2, and a drawing engine 3; the drawing engine 3 consists of a drawing scheduling module 30, a drawing execution module 31, and a data retrieval engine 32; the drawing scheduling module 30 consists of a statistics center module 300, a performance monitoring module 301, and a status monitoring module 302.

[0046] Logic Engine 1 constructs worker threads responsible for executing AJAX requests and performing logical operations in drawing. It assigns a source identifier to each independent AJAX request and each logical operation in drawing. When the data returned by an AJAX request requires further processing, the calculation is completed in Logic Engine 1, and the result, with the source identifier, is sent to intermediate dataset 2. When the data returned by an AJAX request is purely for data logic processing, the calculation is completed in Logic Engine 1, and the result, with the source identifier, is sent to intermediate dataset 2. When the logical operation in drawing is completed, the result, with the source identifier and the drawing method to be used next, is sent to intermediate dataset 2. Logic Engine 1 includes a timer, and each page's timer has a unique ID.

[0047] Intermediate Dataset 2 is an array built based on the UI thread. The larger the index of the array, the newer the data, and the smaller the index, the older the data. Each element in Intermediate Dataset 2 has a unique identifier of its logical source, used to identify whether the data comes from the same processing logic. In addition to storing the data required for drawing, Intermediate Dataset 2 also stores context information, which is metadata indicating where the data comes from and which drawing method should be used for drawing. The context information ensures the logical consistency of the data. Intermediate Dataset 2 has a flag that represents whether it is locked or unlocked, called the lock flag. When logic engine 1 writes data to intermediate dataset 2, it first reads the lock flag. When intermediate dataset 2 is locked, logic engine 1 does not write data to the intermediate dataset. Instead, it starts a timer and reads the lock flag again after the timer completes the interval. Only when the lock flag is unlocked does logic engine 1 complete the operation of writing data to intermediate dataset 2.

[0048] The drawing execution module 31 records drawing functions, each drawing function corresponding to a drawing method. The metadata in the drawing data stored in the intermediate dataset 2 contains the specific drawing method required for each data, which corresponds to the number of the drawing function in the drawing execution module 31.

[0049] Data retrieval engine 32 retrieves data from intermediate dataset 2. When there are no graphics to draw on the page, data retrieval engine 32 performs data retrieval operations from intermediate dataset 2. When data retrieval engine 32 finds no data in intermediate dataset 2, it polls intermediate dataset 2 at regular intervals. This polling period is the time interval between each screen refresh. When the computer maintains a refresh rate of 60 Hz, the polling period is every 16 milliseconds. When data retrieval engine 32 retrieves data from intermediate dataset 2, it sets the lock flag of intermediate dataset 2 to lock it, preventing new data from being entered into intermediate dataset 2. At this time, data retrieval engine 32 performs a deep copy. The data retrieval engine 32 transmits the data from intermediate dataset 2 to the drawing scheduling module 30, then sets the data in intermediate dataset 2 to null and unlocks it. Deep copying ensures that the data used by the drawing scheduling module 30 is different from the data in intermediate dataset 2, preventing information contamination. Furthermore, a deep copy without business logic allows the locking flag of intermediate dataset 2 to be released as quickly as possible, avoiding prolonged or excessive polling operations. After transmitting the data to the drawing scheduling module 30, the data retrieval engine 32 enters a sleep state until the drawing scheduling module 30 sends a start command, at which point the data retrieval engine 32 will restart to retrieve data.

[0050] The function of the drawing scheduling module 30 is to schedule the drawing of page graphics;

[0051] The performance monitoring module 301 contains two monitoring threads: one for page performance monitoring and the other for chart drawing performance monitoring. Page performance monitoring tracks the performance of each page refresh, including two metrics: the refresh interval and memory consumption per refresh. The monitored data is transmitted to the statistics center module 300, a worker thread, for analysis and statistics. The page performance monitoring module transmits data to the statistics center module 300 every second, which then calculates the page's FPS and memory consumption. Chart drawing performance monitoring tracks the time taken to draw each chart during tool development, transmitting the results to the statistics center module 300 after each chart is drawn. The performance monitoring module 301 records the FPS and memory consumption of each page, as well as the drawing time of each chart, in the statistics center module 300.

[0052] The statistics center module 300 categorizes charts based on their plotting time: The first category consists of charts plotted within a single frame, defined as those whose plotting time and execution time are equal in each frame. The second category comprises charts requiring multiple frames to plot, defined as those whose execution time spans multiple frames. The third category consists of resource-intensive charts, defined as those whose FPS is below 30 Hz or whose memory usage exceeds 50% of available memory during plotting. The fourth category consists of charts that cannot run properly on a computer, defined as those whose single-frame execution time exceeds 3 seconds and whose memory consumption consistently exceeds 50% during execution.

[0053] The status monitoring module 302 is mainly used to monitor whether the page is in an active state. When it finds that the page is in an inactive state, the status monitoring module 302 will destroy the timer of the inactive page, thus avoiding invalid timed data retrieval operations.

[0054] When the page is active, the drawing scheduling module 30 reads the data from the statistics center module 300, prioritizes the drawing of the first and second types of charts, releases computer computing resources and refreshes the page when drawing the third type of chart, and gives a prompt that the local configuration cannot draw the fourth type of chart.

Claims

1. An automatic performance monitoring and adjustment device for a browser-based visual development tool, characterized in that... It consists of a logic engine, an intermediate dataset, and a graphing engine; the graphing engine consists of a graphing scheduling module, a graphing execution module, and a data retrieval engine; the graphing scheduling module consists of a statistics center module, a performance monitoring module, and a status monitoring module. The logic engine constructs worker threads responsible for executing AJAX requests and performing logical operations in the drawing process, marking each independent AJAX request and each independent logical operation in the drawing process with a source identifier; when the data returned by the AJAX request requires further processing, the calculation is completed in the logic engine, and the result is marked with a source identifier and sent to the intermediate dataset; when the data returned by the AJAX request is purely data logic processing, the calculation is completed in the logic engine, and the result is marked with a source identifier and sent to the intermediate dataset. When the logical operations in the drawing are completed, the result is added with the source identifier and the drawing method to be used next and sent to the intermediate dataset; the logic engine contains a timer, and the timer of each page has an independent ID identifier; The intermediate dataset is an array built based on the UI thread. The larger the index of the array, the newer the data, and the smaller the index, the older the data. Each element in the intermediate dataset has a unique identifier of its logical source, which is used to identify whether the data comes from the same processing logic. In addition to storing the data required for drawing, the intermediate dataset also stores context information. The context information is a metadata that indicates where the data comes from and which drawing method should be used for drawing. The context information ensures the logical consistency of the data. An intermediate dataset is set with a flag bit that represents whether the intermediate dataset is locked or unlocked, called the lock flag bit. When the logic engine writes data to the intermediate dataset, it first reads the lock flag bit. When the intermediate dataset is locked, the logic engine does not write data to the intermediate dataset. Instead, it starts a timer and reads the lock flag bit again after the timer completes the interval. Only when the lock flag bit is unlocked does the logic engine complete the operation of writing data to the intermediate dataset. The drawing execution module records the drawing functions, and each drawing function corresponds to a drawing method. The metadata in the drawing data stored in the intermediate dataset contains the specific drawing method that each data needs to use, which corresponds to the number of the drawing function in the drawing execution module. The data retrieval engine retrieves data from the intermediate dataset. When there are no graphics to draw on the page, the engine retrieves data from the intermediate dataset. When the engine finds no data in the intermediate dataset, it polls the dataset periodically. This polling period is the time interval between each screen refresh. At a 60Hz refresh rate, this period is 16 milliseconds. Once the engine retrieves data from the intermediate dataset, it sets a lock flag to prevent new data from being entered. At this point, the engine will... The data retrieval engine copies the data from the intermediate dataset and then transmits it to the drawing scheduling module. Afterward, it sets the data in the intermediate dataset to null and unlocks it. A deep copy ensures that the data used by the drawing scheduling module is different from the data in the intermediate dataset, preventing information contamination. Simultaneously, a deep copy without business logic releases the lock flag of the intermediate dataset as quickly as possible to avoid prolonged or excessive polling operations. After transmitting the data to the drawing scheduling module, the data retrieval engine enters a sleep state until the drawing scheduling module sends a start command, at which point the engine restarts to retrieve data. The function of the drawing scheduling module is to schedule the drawing of page graphics; The performance monitoring module comprises two monitoring threads: one for page performance monitoring and the other for chart drawing performance monitoring. Page performance monitoring tracks the performance of each page refresh, including two metrics: the refresh interval and memory consumption per refresh. The monitored data is transmitted to the statistics center module in another worker thread for analysis and statistics. Page performance monitoring transmits data to the statistics center module every second, and the statistics center module calculates the page's FPS and memory consumption. Chart drawing performance monitoring tracks the time taken to draw each chart during tool development, and transmits the results to the statistics center module after each chart is drawn. The performance monitoring module recorded the FPS and memory consumption of each page in the statistics center module, as well as the drawing time of each chart. The statistics center module classifies charts based on their drawing time: the first type of chart is one that is drawn in one frame. The statistical method is that the time for drawing the chart in each frame is the same as the execution time of the chart itself. The second type of chart is one that requires multiple frames to draw. The statistical method is that the execution time of the chart spans multiple frames. The third type of chart is a chart that consumes a lot of resources. The statistical method is to meet the following conditions: the FPS is less than 30 Hz when the chart is drawn, or the memory usage exceeds 50% of the available memory when the chart is drawn. The fourth type of chart is a chart that cannot run properly on a computer. The statistical method is to meet the following conditions: the execution time of a single frame exceeds 3 seconds, and the memory consumption continuously exceeds 50% during the execution. The status monitoring module is mainly used to monitor whether the page is active. When it finds that the page is inactive, the status monitoring module will destroy the timer of the inactive page, thus avoiding invalid timed data retrieval operations. When the page is active, the drawing scheduling module reads the data from the statistics center module, prioritizes the drawing of the first and second types of charts, releases computer computing resources and refreshes the page when drawing the third type of chart, and gives a prompt that the local configuration cannot draw the fourth type of chart.

Images