Page display method, device, equipment and computer readable storage medium

Abstract

This application discloses a page display method, apparatus, device, and computer-readable storage medium. The method includes: acquiring a target event task, wherein the target event task is triggered by a change in the state information of a target component of the page; the target event task includes N computational tasks, where N is an integer greater than 1; determining M worker threads with the minimum resource consumption in a worker thread pool using a Dinic algorithm, where M is an integer greater than 1 and less than or equal to N; executing the N computational tasks using the M worker threads to obtain the execution result of the target event task; and updating the target component displayed on the page using the execution result. This application can improve the efficiency of event task processing.

Description

Technical Field

[0001] This application belongs to the field of display technology, and in particular relates to a page display method, apparatus, device and computer-readable storage medium. Background Technology

[0002] In the existing Vuex framework pattern, when the state of a page component changes, it is submitted to Actions via the Dispatch function. Actions then submit the changes to Mutations via the Commit function. Mutations then modify the state of the page component in the data repository, and the state change is rendered back to the page component, thus updating and displaying the page component.

[0003] However, with the development of computer technology, the number of components on a webpage is increasing daily. For increasingly complex pages, if the Vuex framework pattern described above is still used, the page update efficiency will be low when multiple components on the page change states, since Mutations must be synchronous operations. Summary of the Invention

[0004] This application provides a page display method, apparatus, device, and computer-readable storage medium that can solve the problem of low page update and display efficiency in the prior art.

[0005] In a first aspect, embodiments of this application provide a page display method, the method comprising:

[0006] Obtain the target event task, wherein the target event task is triggered by a change in the state information of the target component of the page; the target event task includes N calculation tasks, where N is an integer greater than 1;

[0007] The Dinic algorithm is used to determine the M worker threads with the minimum resource consumption in the worker thread pool, where M is an integer greater than 1 and less than or equal to N.

[0008] The M worker threads are used to execute the N computational tasks to obtain the execution result of the target event task;

[0009] Using the execution result, update the target component displayed on the page.

[0010] Secondly, embodiments of this application provide a page display device, the device comprising:

[0011] The acquisition module is used to acquire target event tasks, wherein the target event tasks are triggered by changes in the state information of the target component of the page; the target event tasks include N calculation tasks, where N is an integer greater than 1;

[0012] The determination module is used to determine the M worker threads with the minimum resource consumption in the worker thread pool using the Dinic algorithm, where M is an integer greater than 1 and less than or equal to N;

[0013] An execution module is used to execute the N computational tasks using the M worker threads to obtain the execution result of the target event task;

[0014] The display module is used to update the target component displayed on the page using the execution result.

[0015] Thirdly, embodiments of this application provide a page display device, the device comprising:

[0016] Processor and memory storing computer program instructions;

[0017] When the processor executes the computer program instructions, it implements the page display method as described in the first aspect.

[0018] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the page display method as described in the first aspect.

[0019] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the page display method as described in the first aspect.

[0020] In this embodiment, after obtaining an event task triggered by a change in the state information of a page component, the computation task of the event task can be processed in parallel by multiple worker threads to update the page component, thereby improving the efficiency of page update and display. Furthermore, the worker thread executing the computation task of the event task is the worker thread with the lowest resource consumption in the worker thread pool determined by the Dinic algorithm, thus reducing the memory resources consumed by page update and display. Attached Figure Description

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

[0022] Figure 1 This is a schematic diagram of the Vue state management pattern provided in the embodiments of this application;

[0023] Figure 2 This is one of the schematic diagrams of the state management process provided in the embodiments of this application;

[0024] Figure 3 This is a second schematic diagram of the state management process provided in the embodiments of this application;

[0025] Figure 4 This is a flowchart of the page display method provided in the embodiments of this application;

[0026] Figure 5 This is the third flowchart illustrating the state management process provided in this application embodiment;

[0027] Figure 6 This is the fourth schematic diagram of the state management process provided in the embodiments of this application;

[0028] Figure 7 This is a structural diagram of the page display device provided in the embodiments of this application;

[0029] Figure 8 This is a structural diagram of the page display device provided in the embodiments of this application. Detailed Implementation

[0030] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0031] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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 a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0032] For ease of understanding, the following describes some aspects of the embodiments of this application:

[0033] With the rapid development of front-end web visualization, large screens and other display windows are carrying more and more display functions and a large number of complex charts. A large screen page or a PC summary report page needs to load and process a large number of subdivided small chart modules. Different charts on the same page may have redundant and similar data due to different data structures and presentation formats. Each module (also known as a component) on the page requests and communicates with the backend to obtain data and loads itself. Asynchronous loading of each module can be achieved based on framework technologies such as jQuery, React, and Vue.

[0034] This application's embodiments can be applied to the Vue framework, a progressive framework for building user interfaces. Unlike other large frameworks, Vue is designed to be applied layer by layer from the bottom up. Vue's core library focuses only on the view layer, making it easy to learn and integrate with third-party libraries or existing projects. On the other hand, when used in conjunction with modern toolchains and various supporting libraries, Vue is also fully capable of driving complex single-page applications.

[0035] Vue.js is a framework for building user interfaces (a complete solution, highly invasive to projects; changing the framework mid-project requires a complete project refactoring). It focuses solely on the view layer, is easy to learn, and has accompanying third-party libraries. It can improve development efficiency, helping to reduce unnecessary Document Object Model (DOM) operations; it supports two-way data binding, allowing the front-end to focus on business logic without worrying about DOM rendering through framework-provided directives.

[0036] The Web Worker involved in this application is a JavaScript program running in the background, independent of other scripts (i.e., the main page processing script), and will not affect the performance efficiency of the page. Users can continue to do whatever they want: click, select content, etc., while the Web Worker runs in the background. The Web Worker can be used to create a multi-threaded environment for JavaScript, allowing the main thread to create Worker threads and assign tasks to them. While the main thread runs, the Worker threads run in the background, without interfering with each other. The results are returned to the main thread only after the Worker threads have completed their computational tasks. The advantage of this is that some computationally intensive or high-latency tasks are handled by the Worker threads, allowing the main thread (usually responsible for UI interaction) to run smoothly without being blocked or slowed down.

[0037] The Vue framework commonly uses the Vuex framework pattern, which is a state management pattern specifically designed for Vue.js applications. It uses a centralized storage approach to manage the state of all components in the application and ensures that the state changes in a predictable way according to corresponding rules. Essentially, it moves data used by many components to a global location, where all components store and retrieve data, rather than being constrained by a unidirectional data flow within components. Vuex centrally manages this data and provides methods for manipulating it.

[0038] The following is an introduction to the core solutions and mechanisms of Vuex:

[0039] like Figure 1 As shown, a Vuex object structure can include:

[0040] Data warehouse (Store): It acts as a container to hold all the state information in the front-end application and is the only data source for the Vuex framework;

[0041] Getters Figure 1 (Not shown): New states can be derived through Getters;

[0042] Mutations: The only way to commit a Mutation is when the state in the Vuex Store is changed.

[0043] Actions: Actions submit Mutations, not direct changes to the state. Actions can contain any asynchronous operations, but Mutations must be synchronous operations.

[0044] In terms of the operation process, when the state of a component changes, it is submitted to Actions through the Dispatch function, and Actions then submits it to Mutations through the Commit function. At this point, any state change will trigger the rendering of the component in real time.

[0045] A component can contain a view (such as a template), two-way bound data, and methods. All three are written within the same component. Generally, the view triggers a method action, the action affects the data state, and the change in the data state is reflected back in the view, thus forming a closed loop within a component. That is, the view of the current component uses the data of the current component, and the actions (methods) of the current component only modify the data of the current component and do not affect the data of other components.

[0046] In Vuex mode, for dynamic updates of page module content, asynchronous operations are executed through event dispatch and composition using Actions. The results of these asynchronous operations are then submitted to the Mutations. This involves calling asynchronous APIs and dispatching multiple Mutations. Within a component, you can use `this.$store.dispatch('Page displays x')` to dispatch Actions, or use the `mapActions` helper function to map component methods to `store.dispatch` calls.

[0047] Actions and Mutations, as decoupling mechanisms for managing and executing events after they are triggered, aim to address scenarios involving general modular development and dynamic updates. However, when dealing with a large number of modules displayed on a very long screen, numerous built store containers, and the need for reuse and collaborative computation of components and data across multiple stores, the existing workflow repeatedly traverses a large number of process steps based on the triggering requirements of each event. This has also led to several pain points:

[0048] 1. Inflexible scenario services. To ensure real-time data display capabilities, visualization dashboard systems use streaming data processing on the backend to quickly feed data back to the frontend. Data is pushed to the frontend without undergoing complex, time-consuming, and detailed offline calculations in the backend. While the existing Vue modular framework is mainstream in the frontend, it cannot adapt to the efficient mechanisms needed to support the calculation and processing of massive amounts of information such as charts on large screens or PCs.

[0049] 2. Redundant calculations waste resources. When the state of a node in each store container is updated, the source data needs to be reloaded and processed, and a complete virtual DOM needs to be generated. Even if the state change is minor, the entire event handling, update, and calculation process still needs to be completed. This process wastes a lot of browser memory resources.

[0050] 3. Low pressure and efficiency of independent data preprocessing for numerous front-end modules. Each independent module on the front-end page performs its own data organization and processing flow, from acquiring information data to listening, updating, and re-rendering. This involves reprocessing the raw structured data according to the data structure required for display by the module, such as data concatenation, statistics, and structural adjustments. The more modules there are, the more independent data preprocessing programs are executed. This is especially problematic in large-scale thematic analysis pages of the same type, where the same raw data may be displayed differently depending on the perspective of the business analysis. This avoids redundant interfaces that process the same data source with too many module functions under different requests, thus affecting client response efficiency.

[0051] Based on this, in order to meet the increasingly complex page requirements, the need for more comprehensive and intuitive information display, and the improvement of front-end processing efficiency, in the embodiments of this application, such as Figure 2 and Figure 3 As shown, the original basic and general event distribution Actions and change task Mutations stages are redesigned and replaced. An event task parallel management module replaces Actions+Mutations. Within this module, Web Workers and scheduling algorithms are used to construct a mechanism for parallel event task management, allowing for strategy modifications to support future refined technical segmentation optimization and improve efficiency in scenarios involving massive amounts of front-end information computation. In this way, multi-threaded direct parallel processing of task event requirements and data sources, along with task scheduling control, can meet the dynamic update and data computation needs of massive module displays in complex large-screen visualizations. Figure 2 In the diagram, dashed branches represent the flow of related technologies, while solid branches represent the flow of embodiments of this application.

[0052] The page display method provided in this application will be described in detail below with reference to the accompanying drawings and through some embodiments and application scenarios.

[0053] See Figure 4 , Figure 4 This is one of the flowcharts of the page display method provided in the embodiments of this application.

[0054] like Figure 4 As shown, the page display method may include the following steps:

[0055] Step 401: Obtain the target event task, wherein the target event task is triggered by a change in the state information of the target component of the page; the target event task includes N calculation tasks, where N is an integer greater than 1.

[0056] A target component can include one or more components on the page. A target event task can include one or more event tasks. A change in the state information of a component can trigger an event task; therefore, the number of event tasks included in a target event task can be equal to the number of components included in the target component.

[0057] In practice, users can interact with the page, triggering changes in the state information of the target component, which in turn triggers a Vue component state update event, generating a target event task. After obtaining the target event task, it can be broken down into N computational tasks. By using multi-threading to process the computational tasks in the target event task in parallel, the efficiency of event task processing is improved, thereby improving the efficiency of page update and display.

[0058] Step 402: Determine the M worker threads with the minimum resource consumption in the worker thread pool using the Dinic algorithm, where M is an integer greater than 1 and less than or equal to N.

[0059] The number of worker threads in a pool can be one or more. One of the M worker threads can execute one or more computational tasks, which can be determined according to the actual situation. This application does not limit this.

[0060] In this embodiment of the application, a new worker thread is created using web worker technology to asynchronously and parallelly load and process the computational tasks in the event task, and uniformly perform state changes to the data warehouse.

[0061] Furthermore, the Dinic algorithm can be used to monitor the resources of worker threads in the worker thread pool, scan to obtain the resource usage of each worker thread, find the worker thread with the least resource usage in the worker thread pool, and then use the worker thread with the least resource usage to execute the computation task of the event task, which can reduce the memory resources occupied by the event task processing.

[0062] The Dinic algorithm can augment a hierarchical network in stages, which consists of worker threads. In its implementation, the Dinic algorithm can traverse one or more augmentation steps to find the shortest augmenting path, i.e., the worker thread with the least resource consumption. Then, a computational task is assigned to that worker thread, and the traversal is repeated until all computational tasks are assigned.

[0063] Step 403: Execute the N computational tasks using the M worker threads to obtain the execution result of the target event task.

[0064] The Dinic algorithm determines one of the M worker threads and assigns it a computational task.

[0065] In some embodiments, after determining the M worker threads, any one of the M worker threads can directly execute the computational task assigned to it by the Dinic algorithm.

[0066] In other embodiments, after determining the M worker threads, worker threads for computing N computing tasks can be reallocated among the M worker threads to further improve the processing efficiency of the computing tasks. For details, please refer to the relevant description below, which will not be described here.

[0067] Step 404: Using the execution result, update the target component displayed on the page.

[0068] In this embodiment of the application, after the target event task is completed by the worker thread, the execution result of the target event task can be used to directly update the state of the target component in the data warehouse, and the updated state of the target component can be used to render the target component, thereby realizing the update of the target component on the page.

[0069] In this embodiment, the page display method, after obtaining an event task triggered by a change in the state information of a page component, can use multiple worker threads to process the computation task of the event task in parallel, thereby updating the page component and improving the efficiency of page update and display. Furthermore, the worker thread executing the computation task of the event task is the worker thread with the lowest resource consumption in the worker thread pool determined by the Dinic algorithm, thus reducing the memory resources occupied by page update and display.

[0070] In some embodiments, determining the M worker threads with the minimum resource consumption in the worker thread pool using the Dinic algorithm may include:

[0071] The flow information of each worker thread in the worker thread pool is scanned using the Dinic algorithm, wherein the flow information includes at least one of the following: status information, memory usage information, and data processing performance information;

[0072] The minimum number of worker threads required to occupy resources in the worker thread pool is determined using the traffic information.

[0073] The status information of worker threads can be used to determine whether a worker thread is in use or idle. The throughput of a worker thread in use is greater than that of a worker thread in idle state.

[0074] The memory usage information of worker threads can be used to determine the memory consumption of worker threads. The memory usage of worker threads is positively correlated with the traffic of worker threads; that is, the larger the memory usage of a worker thread, the greater the traffic of the worker thread, and vice versa.

[0075] Worker thread data processing performance information can be used to determine the data volume processing performance of a worker thread. This performance can be represented by the size of the taskMap data objects within the worker thread. The data volume processing performance of a worker thread is positively correlated with its throughput; that is, the better the worker thread's data volume processing performance, the higher its throughput, and vice versa.

[0076] The traffic of a worker thread is positively correlated with its resource consumption; that is, the higher the traffic of a worker thread, the higher its resource consumption, and vice versa.

[0077] Based on this, in this embodiment, the Dinic algorithm can be used to scan the traffic information of each worker thread to determine the worker thread with the least resource consumption. In this way, traffic control of computing tasks can be achieved, reducing the memory resources occupied by event task processing.

[0078] In some embodiments, the execution of the N computational tasks using the M worker threads may include:

[0079] Based on the utility function, the target worker thread with the greatest utility among the M worker threads is selected for calculating the i-th computation task among the N computation tasks, where i is a positive integer less than or equal to N.

[0080] The i-th computation task is executed using the target worker thread.

[0081] In this embodiment, after determining the M worker threads with the minimum resource consumption through the Dinic algorithm, before executing the N computational tasks, the optimal scheduling management of the N computational tasks can be achieved based on the heuristic scheduling of utility functions (utility-optimal scheduling algorithm). The tasks are assigned to the resource with the highest utility, i.e., the worker thread, for processing. In this way, the processing efficiency of event tasks can be further improved.

[0082] In practice, a utility-optimal scheduling algorithm can be used to sequentially determine the worker threads with the highest utility for each computational task. It's understandable that as computational tasks are allocated and executed, the utility of each worker thread changes; that is, the allocation and execution of computational tasks affects the utility of each worker thread, which in turn affects the allocation of subsequent computational tasks.

[0083] In this embodiment, a utility-optimal scheduling algorithm based on the utility function can be used to allocate each computing task to the resource with the highest utility for execution. This can further improve the processing efficiency of computing tasks, thereby improving the processing efficiency of event tasks.

[0084] Further, the step of determining the target worker thread with the highest utility among the M worker threads for calculating the i-th computational task among the N computational tasks based on the utility function includes:

[0085] The time utility value of the i-th computation task executed on each worker thread is determined based on the time utility function.

[0086] Based on the cost-utility function, determine the cost-utility value of the i-th computation task executed on each worker thread;

[0087] Based on the time utility value and cost utility value of the i-th computation task executed on each worker thread, the target utility value of the i-th computation task executed on each worker thread is determined, and M target utility values ​​corresponding one-to-one with the M worker threads are obtained.

[0088] The worker thread corresponding to the maximum value among the M target utility values ​​is determined as the target worker thread with the highest utility for calculating the i-th computation task.

[0089] In this embodiment, the worker thread with the highest utility for calculating the computation task can be determined by calculating the target utility value of the task executed on each worker thread. Specifically, the target utility value of the computation task executed on each worker thread is determined based on the time utility value and cost utility value of the computation task executed on each worker thread.

[0090] The time utility value of a computation task executed on a worker thread reflects the time required for that task to execute. This time utility value is positively correlated with the time required for the task to execute on the worker thread; that is, the longer the task takes to execute on the worker thread, the greater its time utility value. In other words, while meeting the deadline of the event task, it's beneficial to execute computation tasks on slower resources whenever possible. This improves the completion rate of the computation task, and slower resources generally have lower costs.

[0091] In some embodiments, the time utility function may be as shown in formula (1), but this does not limit the specific form of the time utility function. It can be set according to actual needs, and this application embodiment does not limit it.

[0092]

[0093] Among them, U t T is the time utility value of the i-th computational task executed on the j-th worker thread; completion time T is the budgeted time for the i-th computation task to be executed on the j-th worker thread; remain time It is the remaining time for the N computing tasks to be executed.

[0094] The cost-utility value of executing a computational task on a worker thread reflects the cost required to execute the task on that thread. The cost-utility value is negatively correlated with the cost required to execute the task on that thread; that is, the lower the cost required, the higher the cost-utility value. In other words, while meeting the budget requirements of the event task, executing computational tasks on resources with lower execution costs can reduce the overall execution cost.

[0095] In some embodiments, the cost-utility function may be as shown in formula (2), but this does not limit the specific form of the cost-utility function. It can be set according to actual needs, and this application embodiment does not limit it.

[0096]

[0097] Among them, U c C is the cost-utility value of executing the i-th computational task on the j-th worker thread; completion cost C is the budgeted cost of the i-th computational task executed on the j-th worker thread; remain cost C is the remaining cost of the N computational tasks up to the current stage; mincost It is the minimum cost of executing the i-th task on the worker thread, that is, the cost of executing the i-th task on the cheapest resource.

[0098] C mincost =budget-C expenses -C onhold Budget is the budgeted cost of the N computational tasks, C expenses C is the cost already incurred by the N computational tasks. onhold It is the sum of the budgeted costs of tasks that are currently being performed but have not yet been completed.

[0099] By using the above methods, time utility functions and cost utility functions can be used to allocate computing tasks to resources with the highest utility, thereby improving the completion rate of computing tasks and reducing the execution cost of computing tasks.

[0100] In some embodiments, the sum of the time utility value and cost utility value of the i-th computation task executed on each worker thread can be directly determined as the target utility value of the i-th computation task executed on each worker thread.

[0101] In other embodiments, determining the target utility value of the i-th computational task executed on each worker thread based on the time utility value and the cost utility value of the i-th computational task executed on each worker thread, and obtaining M target utility values ​​corresponding one-to-one with the M worker threads, includes:

[0102] Obtain the time utility weight value and the cost utility weight value;

[0103] The sum of the first and second values ​​of each worker thread is determined as the target utility value of the i-th computation task executed on each worker thread, thus obtaining M target utility values ​​corresponding one-to-one with the M worker threads.

[0104] Wherein, the first value of each worker thread is the product of the time utility value and the time utility weight value of each worker thread, and the second value of each worker thread is the product of the cost utility value and the cost utility weight value of each worker thread.

[0105] In this embodiment, a weight value is further assigned to the time utility value, namely the time utility weight value, and a weight value is assigned to the cost utility value, namely the cost utility weight value.

[0106] The sum of the time utility weight value and the cost utility weight value is 1.

[0107] In some optional implementations, the time utility weight value and the cost utility weight value can be set according to actual needs. For example, if the user expects to reduce the task execution time, the time utility weight value can be set to be larger; if the user expects to reduce the task execution cost, the cost utility weight value can be set to be larger.

[0108] In some alternative implementations, the time utility weight value W1 can be calculated using formula (3), and the cost utility weight value W2 can be calculated using formula (4):

[0109]

[0110]

[0111] in, The deadline is the budgeted time for the N computational tasks.

[0112] T expect These are the estimated runtime values ​​for the N computational tasks; budget is the budgeted cost of the N computational tasks, C expect It is the estimated operating cost of the N computing tasks.

[0113] T expect It can be any of the following two values ​​or the maximum value:

[0114] The total length of all tasks (i.e., N computational tasks) divided by the average computational speed of the computational resources (i.e., worker threads);

[0115] The length of the longest task divided by the computing speed of the fastest resource.

[0116] C expect It can be the total length of all tasks divided by the average price of the computational resources.

[0117] After obtaining the time utility value and cost utility value of the i-th computation task executed on each worker thread, the time utility value can be multiplied by the time utility weight value to obtain the first value, and the cost utility value can be multiplied by the cost utility weight value to obtain the second value. Then, the first value and the second value are added together to obtain the target utility value. In this way, the reliability of determining the resource with the greatest utility can be improved.

[0118] In some embodiments, the task of obtaining the target event may include:

[0119] Monitor at least one state information corresponding to the target component;

[0120] If a change in the target state information is detected in at least one of the state information, a target event task is generated based on the target state information.

[0121] In some optional implementations, at least one state information corresponding to a component can be encapsulated in a target data structure group. In this implementation, it is possible to determine whether the state information of the component has changed by listening to the data structure group corresponding to the target component, which facilitates the listening of the component's state information.

[0122] In some alternative implementations, monitoring at least one state information corresponding to the target component may include at least one of the following:

[0123] Listen for page size changes and keyboard events;

[0124] Listen for changes in the state of the object;

[0125] When monitoring changes in network routing and navigating to the same page, the Uniform Resource Locator (Url) changes but the view is not reloaded.

[0126] Listen for changes in the browser window size of the page;

[0127] Listen for any change in the status value;

[0128] The issue of the page not refreshing when monitoring the same network route but changing page parameters;

[0129] Register to monitor page refresh and close;

[0130] Monitor webview caching and capture URLs during navigation; monitor page changes.

[0131] The target state information may include one or more of the state information from at least one state information.

[0132] By using the above methods, we can monitor the state information of components and generate event tasks based on the changed state information, thereby improving the reliability of component updates.

[0133] It should be noted that the various optional implementation methods described in the embodiments of this application can be combined with each other or implemented individually without conflict, and the embodiments of this application do not limit this.

[0134] For ease of understanding, the following example is provided:

[0135] In this embodiment, all event tasks of the front-end Vue components are asynchronously and parallelly loaded by creating new threads through web worker technology, and data changes are uniformly made to the data warehouse. The computational traffic of the parallel processing tasks is controlled and managed by the Dinic resource scanning algorithm and the utility scheduling analysis algorithm.

[0136] Normally, a data warehouse is used to store data. If the data needs to be processed and output, such as filtering, merging and connecting data, or performing joint calculations on a large amount of chart data, and if many components need to use this filtered data, such as pie chart components, line chart components, maps, etc., which require the same basic source or need to be combined with each other, this data can be processed and shared in a unified and parallel manner, and output internally and externally through getters.

[0137] The design concept of the embodiments of this application is as follows: Figure 5 As shown:

[0138] Event tasks are processed in the main thread (master) of the event task parallel management module. This thread allocates computational tasks to each worker thread in the thread pool. Simultaneously, a computational traffic algorithm, the Dinic algorithm, is used to continuously refresh and scan the traffic status of each worker thread (Worker thread status > Worker thread memory usage > Worker thread taskMap data object size) to achieve traffic control of computational tasks. Furthermore, a utility-optimal scheduling analysis algorithm is used for unified task management and allocation optimization. This makes the processing flow of front-end Vue components more flexible and controllable, achieving a synergistic architecture where the front-end modular framework and auxiliary support management complement each other.

[0139] The flowchart of the technical solution of the embodiments of this application can be seen as follows: Figure 6 As shown, it includes the following steps:

[0140] Step 1: Getting Started with Store Mode Management

[0141] The core of Vuex is the store repository, which acts as a container to hold all the state information of the front-end components and is the only data source for the Vuex framework.

[0142] By importing the store (index.js file) into the component and initializing it, Vuex saves the root store as the root and stores child module references through the _children property, thus creating a module tree. By registering the store option in the root instance, this store instance will be injected into all child components under the root component, and the child components can access it through this.$store.

[0143] Since Vuex's state storage is reactive, the simplest way to read state from the store instance is to return a state value in a computed property (opens new window). Upon initial execution, the logic will attach the values ​​defined in the module (state, getters, mutations, actions) to the raw module using a new module, and then extract the state into the state property.

[0144] Next, the store is modularized. It can be split into modules for modular management, corresponding to the `modules` property of the configuration object, i.e., a single state tree. A single object contains all application-level state, serving as a "single source of data" (SSOT, which opens new windows). Each component will contain only one store instance. The single state tree allows direct location of any specific state fragment and makes it easy to obtain a snapshot of the current component's state during debugging.

[0145] Module tree and page. The module tree can include a state tree that corresponds to each of the multiple components. The state tree corresponding to a component is used to render the component's state.

[0146] Step 2: Event task listening.

[0147] After the Vue component is initialized and started, this step mainly involves building two services. First, it establishes listeners for eight categories of information through initialization, which can be centrally encapsulated into a set data structure group to facilitate unified state change processing of events. Second, it initializes the multi-threaded concurrent task management of the webworker so that subsequent response operations to event tasks can be carried out through task coordination with its master.

[0148] Initialize Vue component information listener:

[0149] Listen for page size changes and keyboard events;

[0150] Listen for changes in the state of the object;

[0151] When monitoring changes in network routing and navigating to the same page, the URL changes but the view does not reload.

[0152] Monitor browser (page browser) window size changes;

[0153] Listen for any changes in the state value, and listen for mutations and actions;

[0154] The issue of the page not refreshing when the page parameters change on the same route (Vue listens for changes in route parameters and re-renders the page);

[0155] Register to monitor page refresh and close;

[0156] WebView caching and URL interception during navigation, and monitoring page changes.

[0157] Initialize multi-threaded concurrent task management for web workers:

[0158] Web workers operate independently of other scripts (i.e., the main page processing script), and will not affect the performance of rendering and loading on the current page. After creating a multi-threaded environment, the master thread can create worker threads and assign tasks to them. While the main thread runs, the worker threads run in the background, without interfering with each other. The results are returned to the main thread only after the worker threads have completed their computations.

[0159] Step 3: Event, task, and resource status management.

[0160] Based on the event listening task obtained in the previous step, the resource management and task allocation of the Web Worker are dynamically adjusted using the Dinic algorithm. The Dinic algorithm scans the Worker thread status, memory usage, and taskMap data object size within the Worker thread to assign different tasks to different Worker threads.

[0161] First, there is the management of Worker threads, including initializing the number of Worker thread pools and defining the maximum browser memory size occupied by each Worker thread.

[0162] Controlling the number of web worker threads: The `HardWareConcurrecy` property of the `Navagitor` object can be used to obtain the number of CPU cores on the computer hosting the browser. If the CPU has hyper-threading technology, this value is twice the actual number of cores. However, this property has compatibility issues; if the value cannot be obtained, it defaults to 4. The number of worker threads is determined by the number of CPU threads.

[0163] If only one thread is created, all the work is done within that single Worker thread, and there's no guarantee it won't block. If these threads are created indefinitely without control, it can lead to extremely high browser memory consumption when running large-scale visualization applications with numerous modules. By default, a single Web Worker thread incurs an overhead of approximately 5MB.

[0164] Regardless of whether the 5MB of memory is fully used by the Worker thread or is merely a pre-planned memory space for it, this space is indeed occupied, and the frequent creation and termination of threads consumes significant resources. Therefore, the Dinic algorithm can be used to optimize the planning and scheduling of Worker thread work based on the browser's memory resources (total remaining memory outside the main thread), as well as to clean up zombie threads and create new threads.

[0165] Then, the Dinic algorithm is used to monitor the resources of multiple threads and find the shortest augmenting path (i.e. the worker thread with the least resource consumption) among many worker thread pools.

[0166] Dinic algorithm explanation and characteristics:

[0167] Network flow: In a directed graph, select a source and a sink. Each edge has a capacity limit, meaning the flow through this edge cannot exceed this upper bound. Also, except for the source and sink, all other nodes have equal inflow and outflow. The source only experiences outflow, and the sink only experiences inflow. Such a graph is called a network flow.

[0168] The shortest augmenting path algorithm: The idea of ​​the shortest augmenting path algorithm is to find the augmenting path with the fewest arcs in the hierarchical network each time for augmentation.

[0169] The Dinic algorithm works by augmenting the hierarchical network in stages. Unlike the shortest augmenting path algorithm, which requires restarting BFS after each stage of breadth-first search (BFS) to find another augmenting path from the source vertex Vs, the Dinic algorithm achieves multiple augmentations with only one DFS operation. This DFS significantly improves the algorithm's efficiency, which is Dinic's ingenious advantage.

[0170] For any flow, flow rate <= capacity. For any point u that is neither a source nor a sink, equation (5) holds, meaning that the inflow and outflow of a point (excluding the source and sink) are equal:

[0171] ∑p∈Ek[p][u]==∑q∈Ek[u][q] (5)

[0172] Where k[i][j] represents the flow from i to j.

[0173] The Dinic algorithm uses one or more augmenting traversals to find the worker thread with the minimum resource consumption, then performs a task reallocation, and finally re-scans the graph. The Dinic algorithm introduces the concept of a hierarchical graph; the Breadth-First Search (BFS) function finds augmenting paths, while Depth-First Search (DFS) augments the graph along these paths. It first uses a BFS to label all thread nodes, creating a hierarchical graph, and then searches for and updates the graph by finding augmenting paths. The general algorithm flow is as follows:

[0174] a) Use BFS to divide the original graph into layers, that is, label each node. The meaning of this label is the shortest distance from the current node to the source node (assuming that the distance of each edge is 1). Note: When constructing the layered graph, the residual flow of the edges must be greater than 0.

[0175] b) Use Depth-First Search (DFS) to find an augmenting path from the source to the sink. Note: When searching for augmenting paths, follow the order of the hierarchy graph (identified by the Worker thread ID). After finding a path, update the residual flow of all edges based on the minimum residual flow of all edges along this augmenting path (i.e., forward arc - l, reverse arc + l). This mainly includes the Worker thread state (worker's busy is boolean), Worker thread memory usage, and the size of the taskMap data object in the Worker thread.

[0176] c) Repeat step 2. When no augmenting path can be found, repeat step 1 to rebuild the hierarchy until the sink cannot be reached from the source. In other words, quickly scan and summarize the minimum number of worker threads required, and then manage the event tasks.

[0177] Finally, worker threads are managed based on the thread resource usage data obtained from the algorithm scan. Each worker thread declares a task to store received tasks, preparing for a single worker thread to perform multiple tasks simultaneously later. Once a worker thread receives a task request, its isWorking state remains true until the request is completed. Once all worker threads have tasks, requests are initiated directly on the main thread; tasks are not randomly assigned to any worker thread.

[0178] Step 4: Optimal scheduling and management of event task utility.

[0179] This section employs a novel utility function-based heuristic scheduling algorithm (utility-optimal scheduling algorithm) to achieve optimal scheduling management of multi-threaded event tasks. This algorithm uses a utility function approach to comprehensively consider task completion time and runtime cost during scheduling, allocating tasks to resources with the highest utility.

[0180] The goal of this scheduling problem is to optimize scheduling performance. Multiple metrics can be used to comprehensively evaluate the performance of the scheduling algorithm. It is a multi-objective comprehensive optimization problem involving three main performance metrics:

[0181] 1) Task completion rate. The percentage of submitted tasks that are successfully completed while meeting deadline and budget constraints.

[0182] 2) Task execution time. The time difference between when the user submits a task to the scheduler and when the scheduler returns all completed tasks to the user.

[0183] 3) Task execution cost. The sum of the costs of each completed task. The cost of completing each task is the product of the price of the resources used to execute the task and the execution time of the task.

[0184] 4.1 Task Utility Function Analysis

[0185] The design of utility functions for multi-objective worker tasks first requires determining the utility function for each objective.

[0186] 1) The utility function of task execution time: We define the time utility function of task T executing on resource R as follows:

[0187]

[0188] Among them, T completion_time It is the budget for the execution time of task T on resource R, T remain tme This refers to the remaining budget time for the task set to execute. In other words, while meeting the deadline, we should try to execute the task on slower resources. This is beneficial for improving the completion rate of the task set, and slower resources are generally less expensive.

[0189] 2) The utility function of task execution cost: Obviously, the lower the task execution cost, the higher the user satisfaction. Therefore, we define the cost-utility function of task T executed on resource R as follows:

[0190]

[0191] C remain_cost =budget-C expenses -C OnHold

[0192] Among them, C completion_cost It is the budget for the cost of executing task T on resource R; C remain_cost It is the remaining cost of the task set up to this point; C min_cos C is the cost of executing task T on the cheapest resources; expenses C represents the costs already incurred. onHold It is the sum of the cost budgets for tasks that are currently being performed but have not yet been completed.

[0193] 3) Determining the weights. w1 and w2 represent the relative importance of time utility and cost utility, respectively. A larger w1 indicates that the user prefers to reduce task execution time, and vice versa. The specific definitions are as follows:

[0194] wt =deadline / T expect

[0195] w c =budget / C expect

[0196] w1 = w t / (w t +w c )

[0197] w2 = w c / (w t +w c )

[0198] Among them, T expect It is the estimated runtime of the user-submitted task set (the greater of the total length of all tasks divided by the average computing speed of the computing resources and the length of the longest task divided by the computing speed of the fastest resource), C expect It is an estimated cost of running a set of tasks submitted by the user (the total length of the tasks divided by the average price of computing resources).

[0199] 4.2 Task scheduling and allocation.

[0200] Let N represent the number of data update events submitted by a Vue component, T represent the i-th task, M represent the number of resources, and R represent the j-th resource. The allocation logic is as follows: Task T... i Allocated to resource T br ::

[0201]

[0202] Step 5: Task execution and processing.

[0203] This step involves task execution processing following the allocation and management of multi-threaded task coordination resources in the previous step.

[0204] Based on the independent thread programs established for each web worker, the subsequent steps will send data requests to the server backend independently based on the module tag values ​​transmitted from the main thread, using the XMLHttpRequest object for Ajax communication to obtain the specific data required by the module.

[0205] The acquired data is processed independently to meet the needs of handling large amounts of modular data, charts, and other dynamic front-end information changes. This includes information splicing, merging and simplifying displayed data, and performing logical calculations without affecting the loading and rendering efficiency of the browser's main thread.

[0206] Depending on the different data processing efficiency of each web worker, they maintain an independent connection with the web browser's main thread via postMessage and do not affect each other. Due to the characteristics of webworkers, they cannot directly call the browser's page DOM nodes and directly populate and display data information.

[0207] That is, after each web worker completes the data processing according to the business display needs of its respective module, the result data, along with the module's unique identifier, is transmitted to the browser's main thread, triggering the main thread's data listening program to perform DOM operations on the main page's main thread.

[0208] / / Post the processed data result to the main thread

[0209] postMessage({tag:XXX, resultObj: JavaScript object containing the data processing result})

[0210] Because of the nature of WebWorker, it cannot directly call the DOM nodes of the browser page and directly populate and display data information. Each WebWorker transmits the data processing results along with the module's unique identifier to the browser's main thread.

[0211] Step 6: Update the state tree.

[0212] This step updates the front-end module's state tree based on the results of task management and execution following the previous event triggering, and then completes the page rendering of the module through virtualized DOM.

[0213] Whenever `store.state.count` changes, the computed property is re-evaluated, triggering an update of the associated DOM. In a modular build system, state needs to be frequently imported in every component that needs to use it, and state needs to be simulated when testing components.

[0214] In this embodiment, the Vue module displays task event requirements and data source through multi-threaded direct connection and parallel processing. All event tasks of the front-end Vue display modules (i.e., components) are asynchronously and parallelly loaded using web worker technology to create new threads. Data changes are uniformly performed against the state data warehouse, and the computational traffic of parallel processing tasks is controlled and managed using the Dinic resource scanning algorithm and utility scheduling analysis algorithm. This includes:

[0215] A concurrent event task multi-threaded direct connection processing method was designed, replacing the original basic and general decoupled event and task processing. It uses webworker multi-threaded asynchronous parallel loading processing to improve the integrated management and control of event to task processing, rather than the many-to-many mapping and matching processing between events and tasks. It also uniformly faces the state data warehouse for data changes, which efficiently meets the application scenarios of dynamic updates and data calculation for displaying massive information modules in complex large screen visualization.

[0216] This innovative approach integrates the Dinic algorithm for network flow into web visualization to scan, inspect, and manage the computational traffic of modular parallel processing tasks on the front end. It traverses and scans the status, resource consumption, and data volume of all worker threads in the front-end web worker thread pool, quickly summarizing the worker thread with the least resource consumption, and then manages the resource status of event tasks.

[0217] This paper proposes a utility-optimal scheduling algorithm based on a utility function to achieve optimal scheduling management of multi-threaded event tasks. The algorithm considers the completion time and running cost of each worker task, and allocates tasks to the resource with the highest utility during task assignment.

[0218] The embodiments of this application have the following beneficial effects:

[0219] 1. Efficient processing with lower resource consumption. Without affecting the display efficiency of the main page structure, event-based module data update tasks are managed and processed in a unified parallel manner using multi-threading. When processing multiple tasks simultaneously, repeated requests and coordination to cross-module data sources can be reduced, thereby reducing the limited memory resource consumption of the web front-end.

[0220] 2. More flexible in handling complex front-end scenarios. It supports efficient mechanisms for computation and processing of massive amounts of information such as charts on large screens or PCs within a modular agile framework.

[0221] Based on the page display method provided in the above embodiments, this application also provides specific implementations of the page display device. Please refer to the following embodiments.

[0222] See Figure 7 The page display device provided in this application embodiment may include:

[0223] The acquisition module 701 is used to acquire target event tasks, wherein the target event tasks are triggered by changes in the state information of the target component of the page; the target event tasks include N calculation tasks, where N is an integer greater than 1;

[0224] The determination module 702 is used to determine the M worker threads with the minimum resource consumption in the worker thread pool through the Dinic algorithm, where M is an integer greater than 1 and less than or equal to N;

[0225] The execution module 703 is used to execute the N computing tasks using the M worker threads to obtain the execution result of the target event task;

[0226] The display module is used to update the target component displayed on the page using the execution result.

[0227] In some embodiments, the determining module includes:

[0228] The scanning submodule is used to scan the traffic information of each worker thread in the worker thread pool using the Dinic algorithm. The traffic information includes at least one of the following: status information, memory usage information, and data processing performance information.

[0229] The first determining submodule is used to determine the M worker threads with the minimum resource consumption in the worker thread pool using the traffic information.

[0230] In some embodiments, the first execution module includes:

[0231] The second determining submodule is used to determine, based on the utility function, the target worker thread among the M worker threads that has the greatest utility for calculating the i-th computing task among the N computing tasks, where i is a positive integer less than or equal to N;

[0232] An execution submodule is used to execute the i-th computation task using the target worker thread.

[0233] In some embodiments, the second determining submodule includes:

[0234] The first determining unit is used to determine the time utility value of the i-th computation task executed on each worker thread according to the time utility function;

[0235] The second determining unit is used to determine the cost-utility value of the i-th computation task executed on each worker thread according to the cost-utility function;

[0236] The third determining unit is used to determine the target utility value of the i-th computing task executed on each worker thread based on the time utility value and the cost utility value of the i-th computing task executed on each worker thread, and obtain M target utility values ​​corresponding one-to-one with the M worker threads.

[0237] The fourth determining unit is used to determine the worker thread corresponding to the maximum value among the M target utility values ​​as the target worker thread with the highest utility for calculating the i-th computation task.

[0238] In some embodiments, the time utility function is as shown in formula (1):

[0239]

[0240] Among them, U t T is the time utility value of the i-th computational task executed on the j-th worker thread; completion time T is the budgeted time for the i-th computation task to be executed on the j-th worker thread; remain time It is the remaining time for the N computing tasks to be executed up to now;

[0241] The cost-utility function is shown in formula (2):

[0242]

[0243] Among them, U c C is the cost-utility value of executing the i-th computational task on the j-th worker thread; completion cost C is the budgeted cost of the i-th computational task executed on the j-th worker thread; remain cost C is the remaining cost of the N computational tasks up to the current stage; min cost It is the minimum cost of executing the i-th task on the worker thread.

[0244] In some embodiments, the third determining unit is specifically used for:

[0245] Obtain the time utility weight value and the cost utility weight value;

[0246] The sum of the first and second values ​​of each worker thread is determined as the target utility value of the i-th computation task executed on each worker thread, thus obtaining M target utility values ​​corresponding one-to-one with the M worker threads.

[0247] Wherein, the first value of each worker thread is the product of the time utility value and the time utility weight value of each worker thread, and the second value of each worker thread is the product of the cost utility value and the cost utility weight value of each worker thread.

[0248] The time utility weight value W1 is calculated using formula (3), and the cost utility weight value W2 is calculated using formula (4):

[0249]

[0250]

[0251] in, The deadline is the budgeted time for the N computational tasks.

[0252] T expect These are the estimated runtime values ​​for the N computational tasks; budget is the budgeted cost of the N computational tasks, C expect It is the estimated operating cost of the N computing tasks.

[0253] In some embodiments, the acquisition module includes:

[0254] The listening submodule is used to listen to at least one state information corresponding to the target component;

[0255] A generation submodule is used to generate a target event task based on the target state information when a change in the target state information is detected in at least one of the state information.

[0256] The page display device provided in this application embodiment can implement the various processes implemented by the page display device in the method embodiment. To avoid repetition, these processes will not be described again here.

[0257] Figure 8 A schematic diagram of the hardware structure for page display provided in an embodiment of this application is shown.

[0258] The page display device may include a processor 801 and a memory 802 storing computer program instructions.

[0259] Specifically, the processor 801 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0260] Memory 802 may include mass storage for data or instructions. For example, and not limitingly, memory 802 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 802 may include removable or non-removable (or fixed) media. Where appropriate, memory 802 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 802 is non-volatile solid-state memory.

[0261] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0262] The processor 801 implements any of the page display methods in the above embodiments by reading and executing computer program instructions stored in the memory 802.

[0263] In one example, the page display device may also include a communication interface 808 and a bus 810. For example, Figure 8 As shown, the processor 801, memory 802, and communication interface 808 are connected through bus 810 and complete communication with each other.

[0264] The communication interface 808 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0265] Bus 810 includes hardware, software, or both, that couples components of a page display device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 810 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0266] Furthermore, in conjunction with the page display methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the page display methods in the above embodiments.

[0267] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0268] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0269] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0270] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in 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, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0271] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A page display method, characterized in that, include: Obtain the target event task, wherein the target event task is triggered by a change in the state information of the target component of the page; the target event task includes N calculation tasks, where N is an integer greater than 1; The Dinic algorithm is used to determine the M worker threads with the minimum resource consumption in the worker thread pool, where M is an integer greater than 1 and less than or equal to N. The M worker threads are used to execute the N computational tasks to obtain the execution result of the target event task; Using the execution result, update the target component displayed on the page; The step of using the M worker threads to execute the N computational tasks includes: Based on the utility function, the target worker thread with the greatest utility among the M worker threads is selected for calculating the i-th computation task among the N computation tasks, where i is a positive integer less than or equal to N. The i-th computation task is executed using the target worker thread; The step of determining the target worker thread with the highest utility among the M worker threads for calculating the i-th computational task among the N computational tasks based on the utility function includes: The time utility value of the i-th computation task executed on each worker thread is determined based on the time utility function. Based on the cost-utility function, determine the cost-utility value of the i-th computation task executed on each worker thread; Based on the time utility value and cost utility value of the i-th computation task executed on each worker thread, the target utility value of the i-th computation task executed on each worker thread is determined, and M target utility values ​​corresponding one-to-one with the M worker threads are obtained. The worker thread corresponding to the maximum value among the M target utility values ​​is determined as the target worker thread with the highest utility for calculating the i-th computation task.

2. The method according to claim 1, characterized in that, The process of determining the M worker threads with the minimum resource consumption in the worker thread pool using the Dinic algorithm includes: The flow information of each worker thread in the worker thread pool is scanned using the Dinic algorithm, wherein the flow information includes at least one of the following: status information, memory usage information, and data processing performance information; The minimum number of worker threads required to occupy resources in the worker thread pool is determined using the traffic information.

3. The method according to claim 1, characterized in that, The time utility function is shown in formula (1): = （1） in, It is the time utility value of the i-th computation task executed on the j-th worker thread; It is the budgeted time for the i-th computation task to be executed on the j-th worker thread; It is the remaining time for the N computing tasks to be executed up to now; The cost-utility function is shown in formula (2): = （2） in, It is the cost-utility value of the i-th computation task executed on the j-th worker thread; It is the budget cost of the i-th computation task executed on the j-th worker thread; It is the remaining cost of the N computing tasks up to the current point; It is the minimum cost of executing the i-th computation task on the worker thread.

4. The method according to claim 1, characterized in that, The step of determining the target utility value of the i-th computational task executed on each worker thread based on the time utility value and cost utility value of the i-th computational task executed on each worker thread, and obtaining M target utility values ​​corresponding one-to-one with the M worker threads, includes: Obtain the time utility weight value and the cost utility weight value; The sum of the first and second values ​​of each worker thread is determined as the target utility value of the i-th computation task executed on each worker thread, thus obtaining M target utility values ​​corresponding one-to-one with the M worker threads. Wherein, the first value of each worker thread is the product of the time utility value and the time utility weight value of each worker thread, and the second value of each worker thread is the product of the cost utility value and the cost utility weight value of each worker thread. The time utility weight value The cost-utility weight value is calculated using formula (3). The result is obtained by formula (4): （3） （4） in, , It is the budget time for the N computational tasks. These are the estimated runtime values ​​for the N computational tasks; Budget is the budgeted cost of the N computational tasks. It is the estimated operating cost of the N computing tasks.

5. The method according to claim 1, characterized in that, The task of acquiring the target event includes: Monitor at least one state information corresponding to the target component; If a change in the target state information is detected in at least one of the state information, a target event task is generated based on the target state information.

6. A page display device, characterized in that, include: The acquisition module is used to acquire target event tasks, wherein the target event tasks are triggered by changes in the state information of the target component of the page; the target event tasks include N calculation tasks, where N is an integer greater than 1; The determination module is used to determine the M worker threads with the minimum resource consumption in the worker thread pool using the Dinic algorithm, where M is an integer greater than 1 and less than or equal to N; An execution module is used to execute the N computational tasks using the M worker threads to obtain the execution result of the target event task; The display module is used to update the target component displayed on the page using the execution result; The execution module is further configured to determine, based on a utility function, the target worker thread among the M worker threads that has the greatest utility for calculating the i-th computational task among the N computational tasks, where i is a positive integer less than or equal to N; and to execute the i-th computational task using the target worker thread. The execution module is further configured to: determine the time utility value of the i-th computational task executed on each worker thread based on the time utility function; determine the cost utility value of the i-th computational task executed on each worker thread based on the cost utility function; determine the target utility value of the i-th computational task executed on each worker thread based on the time utility value and the cost utility value of the i-th computational task executed on each worker thread, thereby obtaining M target utility values ​​corresponding one-to-one with the M worker threads; and determine the worker thread corresponding to the maximum value among the M target utility values ​​as the target worker thread with the highest utility for calculating the i-th computational task.

7. A page display device, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the page display method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the page display method as described in any one of claims 1 to 5.

Images