Method and system for improving large-scale noise data superposition processing efficiency

Abstract

The invention discloses a method and a system for improving large-scale noise data superposition processing efficiency, and aims to solve the problems that system crash is caused by memory overflow in a large-scale noise data superposition scene, and conventional operation response consumes more than 30 minutes. The method comprises the following steps of: constructing an on-demand real-time calculation framework for storing original data and delay calculation, a hierarchical analysis mechanism (only loading a minimum data set required by interface display for the first time, and carrying out deep analysis delay until being triggered when data is actually called), and a data configuration management strategy of globally unique instance cache combined with local refreshing; the effects that the memory peak value is reduced by more than 70%, the crash risk is thoroughly eliminated, the first loading time is compressed to 0.8 min, the interactive operation is changed into real-time response from non-availability, and the whole-process mapping efficiency is improved to be within ten min from the hour level are achieved.

Description

Technical Field

[0001] This invention belongs to the technical field of data processing, and in particular relates to a method and system for improving the efficiency of processing large-scale noise data overlay. Background Technology

[0002] Currently, mainstream noise analysis tools (such as traditional EDA platforms) generally adopt a full pre-computation architecture when processing the superposition of measurement data under multiple site, multiple device, and multiple bias conditions. The technical path is as follows: 1. Data Loading Phase: The data configuration module parses all measurement files at once, constructing a complete data object tree. For a total of 9600 spectral data points (80 sites × 20 devices × 6 biases), the system will simultaneously store the following in memory: Raw measurement data (sid / sic) Five sets of parameters derived from preprocessing (svg / sib, onoise, inoise, sidovid) 2 ) intermediate result copies of the data parser A complete instance of the drawing object (data_obj).

[0003] 2. Data storage structure: The coordinate sequence is stored using Python's native list and a global index mapping table that can be temporarily rebuilt is maintained, resulting in the peak amount of resident data in memory exceeding 3 times the actual display requirements.

[0004] 3. Visualization rendering: When generating overlay reports, the drawing of symbols for all data points is enabled by default, and curves are displayed by rendering point by point; the legend layout uses a fixed number of columns and font size, which often causes problems such as legend area overflow and coordinate axis obstruction when the diename information of 80 sites is displayed at the same time.

[0005] The above architecture has a fundamental flaw in scenarios with tens of thousands of data points: Memory overflow risk: Loading a full dataset of 9600 records x 1400 data points directly leads to Linux system memory exhaustion, resulting in a 100% crash rate; Severe response delays: routine operations such as closing the data configuration interface and opening the inspection page take more than 30 minutes, and the entire process of generating a graph takes hours. Interaction unavailable: Due to frequent interface lag caused by OCR recognition confirmation, users are unable to complete basic interactions such as selecting a single curve for highlighting. Report generation failed: The static legend layout often causes the legend width to occupy more than 50% of the canvas space, resulting in the drawing area being compressed to the point of being unreadable, and the excessive number of SVG file writes causes an I / O bottleneck.

[0006] Therefore, existing technologies lack a memory-computing collaborative optimization mechanism for scenarios with large-scale noise data overlay, which cannot meet the core needs of industry customers for real-time interactive analysis of tens of thousands of measurement data. There is an urgent need for a method that can systematically reduce memory usage and improve end-to-end processing speed while ensuring statistical accuracy. Summary of the Invention

[0007] The purpose of this invention is to provide a method and system for improving the efficiency of processing large-scale noisy data overlay, thereby reducing memory usage and increasing data processing speed.

[0008] To solve the above problems, the technical solution of the present invention is as follows: A method for improving the efficiency of processing large-scale noisy data overlay includes: The raw measurement data is stored in an unprocessed form, and the required derived parameters are calculated in real time only when the data overlay operation is performed. When loading data for the first time, only the minimum dataset directly related to the interface display is parsed; deep parsing is delayed until the corresponding data is actually called. The data configuration information is cached in a globally unique instance, and each functional interface reads it as needed, and refreshes the corresponding local cache only when the data changes.

[0009] According to an embodiment of the present invention, the derived parameters required for real-time calculation include: dynamically converting the sid / sic values ​​in the original noise data into at least one of svg / sib, onoise, inoise, or sidovid2 during the superposition process.

[0010] According to one embodiment of the present invention, the initial minimum dataset includes: data labels, file paths, and extreme values ​​of sampling point coordinates for interface rendering, excluding all intermediate calculation result data structures.

[0011] According to an embodiment of the present invention, the globally unique instance cache achieves memory optimization in the following manner: Delete the index mapping table that can be temporarily rebuilt, and instead retrieve it dynamically by tag name; Convert the coordinate sequence from a native Python list to a NumPy array structure.

[0012] According to one embodiment of the present invention, when generating an overlay report, a data visualization simplification operation is performed: Traverse all data points along each curve and calculate the angle formed by three consecutive points; When the included angle is within the range of [150°, 210°], delete the intermediate points to reduce the number of curve points by 40%-60%.

[0013] According to one embodiment of the present invention, the overlay report generation process further includes: Plot all measurement data as solid lines, and disable dot symbols; Optimize vector graphics write functions to reduce the number of writes per single SVG file.

[0014] According to an embodiment of the present invention, the data visualization simplification operation further includes an adaptive legend layout algorithm: Pre-calculate the total number of legend items and the width of the drawing area, and dynamically determine the optimal number of columns; When the legend occupies more than 1 / 3 of the total width of the drawing area, iteratively reduce the font size to the preset minimum value or until the legend width meets the proportional limit.

[0015] A system for implementing a method for improving the efficiency of large-scale noisy data overlay processing according to an embodiment of the present invention includes: The delayed computation module is used to store raw data and perform derivative parameter calculations in a reactive manner; The hierarchical parsing engine includes a fast parser and a deep parser, which handle interface loading and simulation requests respectively. The global data manager uses a singleton pattern to cache configuration information and provides a partial refresh interface. The visualization-optimized processor integrates a three-point angle filtering algorithm and a dynamic legend layouter to reduce the memory and computational burden during the data overlay and report generation stages.

[0016] Because the present invention adopts the above technical solution, it has the following advantages and positive effects compared with the prior art: The method for improving the efficiency of large-scale noisy data overlay processing in one embodiment of the present invention fundamentally reverses the memory runaway situation caused by full pre-computation in traditional EDA tools through a collaborative architecture of raw data storage + delayed computation, hierarchical on-demand parsing, and global single-instance caching. The initial loading time is reduced from system freeze to less than 0.8 minutes, and deep parsing only responds instantaneously when triggered by the user, realizing the leap from unavailable to real-time available interactive operation. The global caching mechanism ensures zero duplicate storage of configuration data and partial refresh, reducing the waiting time for routine operations such as closing the configuration page and switching the inspection page from more than 30 minutes to seconds, and ultimately improving the efficiency of the entire process of graph generation from hours to less than ten minutes. Under the premise of ensuring statistical accuracy and visualization integrity, it solves the memory-performance deadlock problem of large-scale noisy data overlay analysis. Attached Figure Description

[0017] Figure 1 This is a flowchart of a method for improving the efficiency of large-scale noise data overlay processing in one embodiment of the present invention; Figure 2 This is a schematic diagram of code for deleting points by trend in one embodiment of the present invention; Figure 3 This is a code diagram illustrating the dynamic adjustment of the number of columns in the legend of a noise inspection report according to an embodiment of the present invention. Figure 4 This is a system block diagram illustrating the efficiency of processing large-scale noise data overlay in one embodiment of the present invention. Detailed Implementation

[0018] The following detailed description, in conjunction with the accompanying drawings and specific embodiments, provides a method and system for improving the efficiency of large-scale noisy data overlay processing according to the present invention. The advantages and features of the present invention will become clearer from the following description and claims.

[0019] Please refer to Figure 1 This embodiment provides a method for improving the efficiency of processing large-scale noisy data overlay, including the following steps: S1: Store the raw measurement data in an unprocessed form and calculate the required derived parameters in real time only when performing data overlay operations; S2: When loading data for the first time, only the smallest dataset directly related to the interface display is parsed; deep parsing is delayed until the corresponding data is actually called. S3: The data configuration information is cached in a globally unique instance, and each functional interface reads it as needed, and refreshes the corresponding local cache only when the data changes.

[0020] This method addresses the issue of system crashes caused by memory overflows and routine operation response times exceeding 30 minutes in scenarios with large-scale noisy data overlay. It achieves the following results: a real-time computing architecture that stores raw data and performs delayed computation; a hierarchical parsing mechanism (loading only the minimum dataset required for interface display on the first load, with deep parsing delayed until the actual data is called); and a data configuration management strategy that combines a globally unique instance cache with partial refresh. These results in a reduction of peak memory usage by more than 70%, completely eliminating the risk of crashes; reducing the initial loading time to 0.8 minutes; transforming interactive operations from unavailable to real-time responsive; and improving the overall graph generation efficiency from hours to within ten minutes.

[0021] Specifically, in step S1, the raw measurement data is stored in its unprocessed form, and the required derived parameters are calculated in real time only when the data overlay operation is performed. The core of this step lies in overturning the traditional EDA tool's full pre-computation model. Through a spatiotemporal reordering strategy of storing raw data and delaying derived calculations, a dynamic balance is established between memory usage and computational efficiency. The specific implementation is as follows: Only the original sampling sequences of the most basic original physical quantities sid (input reference noise voltage) and sic (input reference noise current) in the measurement file are retained, and only this pair of vectors is stored for each data set (approximately 1400 frequency points).

[0022] Completely remove the five types of pre-generated derived data structures (svg / sib, onoise, inoise, sidovid) from the traditional architecture. 2 These derivatives would require approximately four times more memory per spectrum in the old scheme.

[0023] The coordinate sequence is converted from a native Python list to a numpy.ndarray, utilizing contiguous memory layout and low-level C implementation, reducing the memory usage of a single data entry by approximately 20%.

[0024] The real-time calculation of derived parameters is strictly postponed to the post-simulation data overlay stage, specifically triggered by the following conditions: User-driven operation: The required derived parameters are only calculated for the first time when the system enters the overlay process after the user has completed all configurations (such as selecting 80 sites, specifying bias conditions, clicking compare to data) and started the simulation.

[0025] On-demand local calculation: Instead of calculating all derived data, it dynamically converts sid / sic into a single target parameter based on the current overlay plot's kop (key operating parameter) requirements (e.g., calculating only onoise for 1 / f noise analysis, or only svg for voltage spectral density comparison).

[0026] Perform vector operations temporarily in memory, for example: onoise = sid 2 + sic 2 × Z 2 (Z is the device impedance); SVG = sqrt(sid) and other series of conversions; The calculation is used for plotting immediately after completion. Intermediate results are not cached, and the calculation instance is garbage collected as soon as it exits the function stack.

[0027] The memory usage of the derived parameters changed from a constant peak to an instantaneous peak, and was automatically released after the overlay was completed, reducing the memory peak by about 40%.

[0028] This step shifts computation from the data loading stage to the visualization rendering stage, utilizing the time gaps in user operations to complete the necessary calculations, thus changing memory pressure from persistent to transient. It is a typical engineering innovation that uses time-series reconstruction to solve spatial congestion.

[0029] In step S2, during the initial data loading, only the smallest dataset directly related to the interface display is parsed; deep parsing is delayed until the corresponding data is actually accessed. This step restructures the data loading process from the traditional one-time full parsing to a phased, on-demand triggered lightweight pipeline by building a dual-mode engine of fast parsing + deep parsing. The specific implementation is as follows: During the fast parsing phase, the minimum dataset loaded initially includes: Metadata layer: Only extract data labels, file paths, and XY coordinate extreme values ​​(used for calculating the range of the interface scroll bar); Index layer: Constructs statistical information on the number of spectrums (e.g., 80 sites × 20 devices × 6 bias = 9600 spectrum counts), without reading any frequency point values; Display layer: If the data window interface needs to display a preview, then only the first 10 frequency points of each curve are sampled for thumbnail rendering.

[0030] Actively excluded items: It does not parse the complete SID / SIC numerical sequence of 1400+ frequency points; Do not perform spectrum validity checks (such as missing value detection and abnormal jump point filtering); No derived parameters are generated (such as svg / sib and other five types of results); Do not instantiate the data parser result object (this reduces memory usage by 16%).

[0031] At this stage, memory usage is less than 10% of the full parsing, and loading the configuration information for 9,600 spectrum entries takes only 0.8 minutes. In contrast, the traditional method would cause the Linux system to crash due to memory exhaustion at this stage.

[0032] During the deep parsing phase: Deep parsing is strictly postponed until the user's explicit operation triggers the actual use of the data. Triggering scenarios include: Single Check Simulation Startup: After the user selects a noise check on the check page and clicks "Run", the system will load the data corresponding to the selected label of that check as needed (e.g., only load the selected 200 from 9600). Report generation phase: Before overlay plotting, temporarily parse the complete 1400-point SID / SIC data of the target spectrum; Interactive highlighting: When a user clicks on the legend to select a site, the detailed data of that site is parsed in real time and the highlight curve is rendered.

[0033] The above steps employ the lazy proxy pattern: upon initial load, each label in the data config corresponds to a lightweight proxy object, which only holds the file handle and offset pointer; When the get_full_spectrum() method is called, the proxy object performs file I / O to read the complete data block and temporarily instantiates the deep parser; After parsing, the complete data resides only in the local cache of the currently active Check, and is garbage collected when the check page is closed.

[0034] In addition, this step also employs a collaborative mechanism of global caching and partial refresh: Global caching: Data config items (such as label mapping relationships and file path dictionaries) reside in memory in singleton mode, and are shared across all interfaces (data window, check page, report viewer) with zero copying; Partial refresh: Each functional interface holds an independent data view and is refreshed only in the following situations: When a user modifies the bias setting of a label in the data config, only the data structure corresponding to that label is refreshed. Switch to the check page tab to load only the check data required for the current tab; Save the project, serialize only the modified label configurations, and skip the unchanged data.

[0035] Step S2, through precise time-for-space scheduling, breaks down the two memory killers—I / O-intensive parsing and computationally intensive derivative parameter calculation—into distributed execution during user operation intervals. This reduces the theoretical peak memory usage for 9600 spectrum lines from >8GB in traditional solutions to <2GB. While ensuring data integrity and analysis accuracy, it transforms large-scale noise data analysis from a batch processing offline task into an interactive online operation.

[0036] In step S3, the data configuration information is cached using a globally unique instance. Each functional interface reads the information as needed, and the corresponding local cache is refreshed only when the data changes. This step restructures the access mode of the data configuration information from repeated loading to zero-copy sharing and incremental updates by constructing a two-level storage architecture of a single-instance global cache and multiple-view local caches. The globally unique instance cache achieves memory optimization in the following ways: Delete the index mapping table that can be temporarily rebuilt, and instead retrieve it dynamically by tag name; Convert the coordinate sequence from a native Python list to a NumPy array structure.

[0037] The specific implementation is as follows: Globally unique instances include: Singleton Implementation: A process-level singleton pattern is adopted. A `DataConfigManager` object is instantiated in the heap memory's resident area when the EDA tool starts. All functional modules access it through a global reference `$GLOBAL_DATA_CONFIG`, eliminating redundancy from multiple copies. Its cached content (only configuration metadata, excluding complete waveform data) includes: Label mapping dictionary: {label_name: <filemeta>}, where FileMeta only contains descriptive fields such as file path, data type, site information (xy die coordinates), and bias conditions; Tree structure index: The tree structure reflects the hierarchical relationship of 80 sites × 20 devices × 6 bias. Each node only stores pointers to child nodes and statistical counts, and does not carry actual spectrum data. Change flag: Each label corresponds to a dirty_flag boolean value, which is initially False and is only set to True when the user modifies the label configuration in the data config interface.

[0038] The size of the global instance is independent of the amount of data. The configuration information for 9600 spectrums resides in memory for less than 50MB, while traditional solutions consume more than 500MB of memory due to repeated loading.

[0039] Regarding the functional interface, this embodiment adopts an on-demand read mechanism (zero-copy access), including: Interface-level data views, such as: Data Window interface: Calls $GLOBAL_DATA_CONFIG.get_label_list() to get the label list and renders a tree control, without loading any frequency data; when scrolling, only the label_name and bias summary of the visible area are requested; Check Page interface: After the user checks "compare to data" and selects 200 labels, $GLOBAL_DATA_CONFIG.get_selected_meta(labels) is called to get the FileMeta list of the selected labels. The returned value is a reference (pointer) to the object in the global instance, not a deep copy. Report generation module: When overlay plotting, the file is located directly through FileMeta.file_path, the original data blocks are read as needed, parsed and temporarily stored in the local cache, and the lifespan is limited to the current report drawing cycle.

[0040] During read operations, all interfaces read only the global instance, and no interface is allowed to hold a private copy of the configuration data. Each interface filters the view according to its business needs. For example, the check page only extracts nodes whose label_name contains Site_01. The filtering logic is executed at the application layer and does not trigger global data reorganization.

[0041] Regarding partial cache flushing, the refresh triggering mechanism includes: $GLOBAL_DATA_CONFIG.refresh(label_id) is only triggered when the Save button is clicked in the data config interface; the refresh function is executed only for a single label with dirty_flag=True, rather than a full rebuild.

[0042] During an update, if a user changes the bias of a label from 3V to 5V in the data config, the system will only set the dirty_flag of that label to True, without immediately writing to disk or flushing memory. When the user closes the data config interface, the system iterates through all dirty_flags and executes the following for labels that are True: Re-parse the file corresponding to this label (20 devices × 6 bias = 120 spectra). Update the FileMeta object property of this label in the global instance; Mark the local cache of this label (if it exists on an active check page) as stale, and it will automatically expire and be reloaded on the next visit.

[0043] If an activity check page is using this label, a partial view refresh of that check will be triggered, while other unaffected check pages will remain unchanged and will not need to be reloaded.

[0044] Compared to the traditional approach which requires re-serializing 9600 spectrum information entries, taking 30+ minutes, the above method only refreshes and changes the labels, taking less than 1 second. Furthermore, compared to the traditional approach which reloads all data from disk, taking more than 10 minutes, this method directly reads the global instance and can complete the process instantly.

[0045] When generating the overlay report, perform a data visualization simplification operation: Traverse all data points along each curve and calculate the angle formed by three consecutive points; When the included angle is within the range of [150°, 210°], delete the intermediate points to reduce the number of curve points by 40%-60%.

[0046] Specifically, the reduction in time consumption for generating overlay reports mainly includes: removing some points according to trends (reducing time and memory usage by approximately 50%); displaying measurement data entirely as solid lines instead of symbols (from hourly to minute-level data); and optimizing the write function to reduce the number of times the SVG file is read (reducing file write time by approximately 50%). For details on removing some points according to trends, please refer to [link / reference needed]. Figure 2 The system checks all points on each curve of the overlay, iteratively calculates the angle between every three adjacent points, and deletes intermediate points with angles between [150, 210]. Furthermore, during the overlay report generation process, all measurement data is drawn as solid lines, and dotted symbols are disabled; the vector graphics writing function is optimized to reduce the number of writes to a single SVG file.

[0047] Furthermore, the data visualization simplification process also includes an adaptive legend layout algorithm: Pre-calculate the total number of legend items and the width of the drawing area, and dynamically determine the optimal number of columns; When the legend occupies more than 1 / 3 of the total width of the drawing area, iteratively reduce the font size to the preset minimum value or until the legend width meets the proportional limit.

[0048] For details, please refer to Figure 3 When dynamically adjusting the number of columns for the legend in the noise inspection report, the optimal number of columns is calculated based on the content and available space to ensure the legend is properly arranged within the drawing area. This includes the following steps: Initial checks: Verify that the required items exist and that the y-axis name is in the predefined list. If not, return prematurely. Legend layout settings: Get the rectangular area rect of the legend and its content layout; Adjust legend item margins: Iterate through each item in the layout, and for QwtLegendItem type controls, set their margins to zero; Calculate the number of columns and items per column: Determine the initial number of columns based on the legend's width, obtain the arranged items, and calculate the relative height. Count the number of items that can be accommodated within this relative height to determine the number of rectangles that can be placed in each column; Determine the optimal number of columns: Adjust the number of columns in a loop to ensure all items are accommodated without exceeding the available space. If adding one more column is beneficial to the layout, set a new maximum number of columns; Update layout and font size: Apply the new number of columns to the layout. If the legend width exceeds one-third of the total width and the current font size is greater than 1 point, reduce the font size by 1 point and recursively call the function to readjust.

[0049] By employing the methods described above to improve the efficiency of processing large-scale noisy data overlays, with a data volume of 80 dies * 20 devices * 6 biases * 1443 frequency = 13.8 million points, the following improvements are achieved compared to the previous method: Because the data loading process is placed in the simulation, the simulation rendering time for the first check will increase to about 10 minutes, while having almost no impact on the simulation rendering time for the second and subsequent checks.

[0050] Based on the same concept, this embodiment also provides a system for implementing the above-described method for improving the efficiency of large-scale noise data overlay processing. Please refer to [link / reference]. Figure 4 The system includes: The delayed computation module is used to store raw data and perform derivative parameter calculations in a reactive manner; The hierarchical parsing engine includes a fast parser and a deep parser, which handle interface loading and simulation requests respectively. The global data manager uses a singleton pattern to cache configuration information and provides a partial refresh interface. The visualization-optimized processor integrates a three-point angle filtering algorithm and a dynamic legend layouter to reduce the memory and computational burden during the data overlay and report generation stages.

[0051] The specific implementation of this system is similar to the implementation of the method for improving the efficiency of large-scale noise data overlay processing described above, and will not be repeated here.

[0052] In summary, the method and system for improving the efficiency of large-scale noise data overlay processing in this embodiment, through a collaborative architecture of raw data storage + delayed computation, hierarchical on-demand parsing, and global single-instance caching, fundamentally reverses the memory runaway situation caused by full pre-computation in traditional EDA tools. This reduces the peak memory usage in the scenario of overlaying 9600 spectrum curves by more than 70%, completely eliminating the risk of loading crashes. The initial loading time is reduced from system freeze to less than 0.8 minutes, and deep parsing only responds instantaneously when triggered by the user, achieving a leap from unavailable to real-time available interactive operations. The global caching mechanism ensures zero duplicate storage and partial refresh of configuration data, reducing the waiting time for routine operations such as closing the configuration page and switching the inspection page from more than 30 minutes to the second level. Ultimately, the efficiency of the entire process of graph generation is improved from hours to less than ten minutes. While ensuring statistical accuracy and visualization integrity, it solves the memory-performance deadlock problem in large-scale noise data overlay analysis.

[0053] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings, but the present invention is not limited to the above embodiments. Even if various changes are made to the present invention, if these changes fall within the scope of the claims of the present invention and their equivalents, they shall still fall within the protection scope of the present invention.< / filemeta>

Claims

1. A method for improving the efficiency of processing large-scale noisy data overlay, characterized in that, include: The raw measurement data is stored in an unprocessed form, and the required derived parameters are calculated in real time only when the data overlay operation is performed. When loading data for the first time, only the minimum dataset directly related to the interface display is parsed; deep parsing is delayed until the corresponding data is actually called. The data configuration information is cached in a globally unique instance, and each functional interface reads it as needed, and refreshes the corresponding local cache only when the data changes.

2. The method for improving the efficiency of large-scale noise data overlay processing according to claim 1, characterized in that, The derived parameters required for the real-time calculation include: dynamically converting the sid / sic values ​​in the original noise data into at least one of svg / sib, onoise, inoise, or sidovid2 during the superposition process.

3. The method for improving the efficiency of large-scale noise data overlay processing according to claim 1, characterized in that, The initial minimum dataset includes: data labels, file paths, and extreme values ​​of sampling point coordinates used for interface rendering, excluding all intermediate calculation result data structures.

4. The method for improving the efficiency of large-scale noise data overlay processing according to claim 1, characterized in that, The globally unique instance cache achieves memory optimization in the following ways: Delete the index mapping table that can be temporarily rebuilt, and instead retrieve it dynamically by tag name; Convert the coordinate sequence from a native Python list to a NumPy array structure.

5. The method for improving the efficiency of large-scale noise data overlay processing according to claim 1, characterized in that, When generating the overlay report, perform a data visualization simplification operation: Traverse all data points along each curve and calculate the angle formed by three consecutive points; When the included angle is within the range of [150°, 210°], delete the intermediate points to reduce the number of curve points by 40%-60%.

6. The method for improving the efficiency of large-scale noise data overlay processing according to claim 5, characterized in that, The process of generating the overlay report also includes: Plot all measurement data as solid lines, and disable dot symbols; Optimize vector graphics write functions to reduce the number of writes per single SVG file.

7. The method for improving the efficiency of large-scale noise data overlay processing according to claim 5, characterized in that, The simplified data visualization operation also includes an adaptive legend layout algorithm: Pre-calculate the total number of legend items and the width of the drawing area, and dynamically determine the optimal number of columns; When the legend occupies more than 1 / 3 of the total width of the drawing area, iteratively reduce the font size to the preset minimum value or until the legend width meets the proportional limit.

8. A system for implementing the method as described in any one of claims 1-7, characterized in that, include: The delayed computation module is used to store raw data and perform derivative parameter calculations in a reactive manner; The hierarchical parsing engine includes a fast parser and a deep parser, which handle interface loading and simulation requests respectively. The global data manager uses a singleton pattern to cache configuration information and provides a partial refresh interface. The visualization-optimized processor integrates a three-point angle filtering algorithm and a dynamic legend layouter to reduce the memory and computational burden during the data overlay and report generation stages.

Images