Code optimization caching method and device, equipment and storage medium
By breaking down the initial code file into independent sub-modules and establishing a global dependency graph, the caching scheme is optimized, solving the problem of redundant code in existing technologies and achieving efficient code caching and a fast build process.
Patent Information
- Application Number
- CN202511690440.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-18
- Publication Date
- 2026-03-03
AI Technical Summary
Existing caching solutions lack global analysis of dependencies, resulting in cached content containing a large amount of redundant code, which wastes storage resources. Furthermore, the browser still needs to load and parse invalid code, so the caching performance cannot reach its optimal state.
The initial code file is broken down into independent sub-modules, a local dependency graph is built and merged into a global dependency graph, each sub-module is optimized using the global dependency graph, the target code file is generated and fine-grained caching is performed.
It achieves efficient and accurate code optimization caching, reduces redundant code, improves caching performance, and speeds up the build, test, and deployment process.
Smart Images
Figure CN121597215A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of code optimization caching technology, specifically to a code optimization caching method, apparatus, device, and storage medium. Background Technology
[0002] In modern web front-end development, JavaScript modular build tools have become a core component of the development process. As project size increases and third-party dependencies grow, traditional build tools (such as Webpack, Rollup, Vite, etc.) face significant performance bottlenecks during the development phase, hence the widespread adoption of caching mechanisms to improve build performance.
[0003] However, existing caching solutions lack global analysis of dependencies, resulting in cached content containing a large amount of redundant code. This coarse-grained caching mechanism not only wastes storage resources, but more seriously, the browser still needs to load and parse this invalid code, making it impossible for the caching performance to reach its optimal state. Summary of the Invention
[0004] In view of this, this application provides a method, apparatus, device, and storage medium for optimizing code caching, which addresses the problem that existing caching schemes lack global analysis of dependencies, resulting in cached content containing a large amount of redundant code. This coarse-grained caching mechanism not only wastes storage resources, but more seriously, the browser still needs to load and parse this invalid code, making it impossible for the caching performance to reach its optimal state.
[0005] To achieve the above objectives, the following solution is proposed:
[0006] Firstly, a code optimization caching method includes:
[0007] The initial code file to be optimized is broken down into the first code file corresponding to each independent submodule;
[0008] Establish a local dependency graph corresponding to each of the independent sub-modules;
[0009] The local dependency graphs corresponding to each of the independent sub-modules are merged to obtain the global dependency graph;
[0010] Using the global dependency graph, the first code file corresponding to each independent submodule is optimized to obtain the target code file;
[0011] The target code file corresponding to each of the independent sub-modules is cached.
[0012] Preferably, the step of decomposing the initial code file to be optimized into each independent sub-module corresponding to each first code file includes:
[0013] Read the initial code file to identify the individual initial submodules within it;
[0014] Rewrite each of the initial submodules using the Rust language;
[0015] Create an API interface for each rewritten initial submodule to obtain each independent submodule;
[0016] Generate a first code file corresponding to each of the aforementioned independent submodules.
[0017] Preferably, establishing the local dependency graph corresponding to each of the independent sub-modules includes:
[0018] Create individual threads;
[0019] Load each of the aforementioned threads and instantiate the independent submodules corresponding to each of the aforementioned threads to obtain each target thread;
[0020] Determine the dependency tree corresponding to the initial code file;
[0021] The dependency tree is split into subtrees for parallel processing;
[0022] For each target thread, the target thread initiates a task request to the main thread, so that the main thread can determine a corresponding subtree from each of the subtrees as the target subtree corresponding to the target thread;
[0023] The target subtree is assigned to the target thread so that the target thread can load the corresponding independent subtree to generate a local dependency graph.
[0024] Preferably, the creation of each target thread includes:
[0025] Detect the number of CPU cores in the current device;
[0026] Get the main thread processing speed;
[0027] The number of CPU cores and the main thread processing speed are standardized to obtain a first standard value and a second standard value.
[0028] The target score is obtained by weighted summation of the first and second standard values;
[0029] A first threshold is set based on the target score;
[0030] Create the target number of threads corresponding to the first threshold.
[0031] Preferably, the step of assigning the target subtree to the target thread so that the target thread can load the corresponding independent subtree to generate a local dependency graph includes:
[0032] Read the file content and file extension corresponding to the target subtree;
[0033] A parser is selected based on the file extension, and the parser is used to parse the file content into an abstract syntax tree;
[0034] Traverse each node in the abstract syntax tree to determine the unique identifier, the exported interface, and the dependencies between the nodes.
[0035] A local dependency graph corresponding to the independent submodule is generated based on the unique identifier, the exported interface, and the dependencies between the nodes.
[0036] Preferably, the step of optimizing the first code file corresponding to each independent submodule using the global dependency graph to obtain the target code file includes:
[0037] Each exported interface is determined from the global dependency graph;
[0038] Determine if there are any unused export interfaces. If so, determine the first code file containing the unused export interface, remove the code corresponding to the unused export interface, and obtain the second code file.
[0039] The local variable names in the second code file are compressed, and all comments and whitespace characters are removed to obtain the third code file;
[0040] The third code file is standardized to obtain the fourth code file;
[0041] Calculate the hash value of the fourth code file, and select the first N bits of the hash value as the target hash;
[0042] The target hash is used to mark the third file to obtain the target code file.
[0043] Preferably, caching the target code file corresponding to each of the independent sub-modules includes:
[0044] Obtain the original path of each independent submodule and the file path of the corresponding target code file;
[0045] For each of the aforementioned independent submodules, an index table is created based on the original path and file path of the independent submodule;
[0046] The index table of each of the independent sub-modules is cached separately.
[0047] Secondly, a code optimization caching device includes:
[0048] The decomposition module is used to decompose the initial code file to be optimized into each first code file corresponding to each independent sub-module;
[0049] A local dependency graph building module is used to build a local dependency graph corresponding to each of the independent sub-modules.
[0050] The merging module is used to merge the local dependency graphs corresponding to each of the independent sub-modules to obtain a global dependency graph.
[0051] An optimization module is used to optimize the first code file corresponding to each independent submodule using the global dependency graph to obtain the target code file;
[0052] The caching module is used to cache the target code files corresponding to each of the independent sub-modules.
[0053] Thirdly, a code optimization caching device, including memory and processor;
[0054] The memory is used to store programs;
[0055] The processor is configured to execute the program to implement the steps of the optimized caching method for the code as described in any of the first aspects.
[0056] Fourthly, a storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the optimized caching method for the code as described in any of the first aspects.
[0057] As can be seen from the above technical solution, this application decomposes the initial code file to be optimized into each first code file corresponding to each independent sub-module; establishes a local dependency graph corresponding to each independent sub-module; merges the local dependency graphs corresponding to each independent sub-module to obtain a global dependency graph; uses the global dependency graph to optimize the first code file corresponding to each independent sub-module to obtain a target code file; and caches the target code file corresponding to each independent sub-module. This application first breaks down the initial code file to be optimized for caching, thus refining the initial code file to obtain the first code file corresponding to each independent submodule. Then, a local dependency graph corresponding to each independent submodule is established to analyze the internal dependencies of each independent submodule. The scattered dependencies are then merged to identify cross dependencies, circular dependencies, implicit dependencies, etc., between independent submodules. This allows for precise optimization of the first code file corresponding to each independent submodule using the global dependency graph, preventing the omission of relationships between independent submodules and implementing fine-grained caching for each independent submodule. This achieves efficient and fast caching optimization and can also accelerate subsequent build, testing, and deployment processes. Attached Figure Description
[0058] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0059] Figure 1 An optional flowchart of a code optimization caching method provided in an embodiment of this application;
[0060] Figure 2 A schematic diagram of the structure of a code optimization caching device provided in an embodiment of this application;
[0061] Figure 3 This is a schematic diagram of the structure of a code optimization caching device provided in an embodiment of this application. Detailed Implementation
[0062] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0063] This invention can be used in a wide variety of general-purpose or special-purpose computing environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, distributed computing environments including any of the above devices, etc.
[0064] This invention provides a code optimization caching method, which can be applied to various computer terminals or smart terminals. The executing entity can be the processor or server of the computer terminal or smart terminal. The method flowchart is shown below. Figure 1 As shown, it specifically includes:
[0065] S1: Decompose the initial code file to be optimized into the first code file corresponding to each independent submodule.
[0066] The initial code file for caching optimization can be any large functional module with caching optimization requirements, such as ESBuild. It can be broken down, and during the decomposition process, it can be broken down according to all the functions or core functions it implements, resulting in a file reading submodule, a syntax parsing submodule, a dependency extraction submodule, a TypeScript conversion module, etc. In addition, it is necessary to ensure that the functional effect of the independent submodule after decomposition is consistent with the effect of the small function that the large functional module before decomposition could achieve. At the same time, memory management can be optimized and multi-threading support can be implemented.
[0067] After identifying the individual submodules, it is also necessary to use Emscripten's wasm-pack tool to generate WASM binary files and export the necessary function interfaces for JavaScript to call.
[0068] S2: Establish a local dependency graph corresponding to each of the independent sub-modules.
[0069] Each local dependency map can be built independently without interfering with each other, which makes it possible to use multi-core processors for property analysis to improve the overall processing speed.
[0070] S3: Merge the local dependency graphs corresponding to each independent submodule to obtain the global dependency graph.
[0071] This step integrates scattered local information into a unified global dependency relationship, which can summarize cross dependencies, circular dependencies, and implicit dependencies between independent sub-modules. This is the core basis for optimizing caching. In other words, only by starting from a global perspective can better optimization opportunities be found.
[0072] For example, if independent submodule A and independent submodule B both reference the same utility function, they can be extracted as a shared module.
[0073] S4: Using the global dependency graph, optimize the first code file corresponding to each independent submodule to obtain the target code file.
[0074] This step is based on global dependency graph optimization, ensuring the correctness, efficiency, and security of the optimization.
[0075] For example, if it can accurately determine whether a function or variable is truly not used anywhere, by any other independent submodule, or by any other large module, then it can be removed; it can also perform cross-module code merging, convergence, and splitting to generate smaller, more efficient code.
[0076] It also allows for personalization. Since the global dependency graph is constructed from the local dependency graphs of each independent submodule, optimization can be performed based on the characteristics of each independent submodule, rather than adopting a one-size-fits-all approach that could affect the optimization accuracy.
[0077] S5: Cache the target code file corresponding to each of the independent sub-modules.
[0078] This application caches individual submodules rather than entire large modules, achieving efficiency and fine-grained caching. It can support incremental updates, meaning that when the target code file changes, only the changed and affected individual submodules need to be updated, optimized, and cached. The caches of other individual submodules can be directly reused, accelerating the subsequent build, testing, and deployment processes. In addition, in browser or client environments, fine-grained caching means that users only need to download the changed code blocks, rather than the entire application package, thereby speeding up loading.
[0079] As can be seen from the above technical solution, this application decomposes the initial code file to be optimized into each first code file corresponding to each independent sub-module; establishes a local dependency graph corresponding to each independent sub-module; merges the local dependency graphs corresponding to each independent sub-module to obtain a global dependency graph; uses the global dependency graph to optimize the first code file corresponding to each independent sub-module to obtain a target code file; and caches the target code file corresponding to each independent sub-module. This application first breaks down the initial code file to be optimized for caching, thus refining the initial code file to obtain the first code file corresponding to each independent submodule. Then, a local dependency graph corresponding to each independent submodule is established to analyze the internal dependencies of each independent submodule. The scattered dependencies are then merged to identify cross dependencies, circular dependencies, implicit dependencies, etc., between independent submodules. This allows for precise optimization of the first code file corresponding to each independent submodule using the global dependency graph, preventing the omission of relationships between independent submodules and implementing fine-grained caching for each independent submodule. This achieves efficient and fast caching optimization and can also accelerate subsequent build, testing, and deployment processes.
[0080] Traditional caching may be based on the entire project or a large module. Once a small part of the code changes, the entire cache will become invalid, resulting in a low cache hit rate. This application splits the initial code file into independent sub-modules and establishes a global dependency graph. The system can accurately understand the dependency relationship of each independent sub-module. Optimization and caching can then be precise at the level of independent sub-modules. When an independent sub-module changes, only the independent sub-modules that directly or indirectly depend on it need to be re-optimized and cached. The caches of other unaffected sub-modules can continue to be used, thereby improving cache utilization.
[0081] The method provided in this embodiment of the invention involves decomposing the initial code file to be optimized into first code files corresponding to each independent sub-module. The specific details are as follows:
[0082] Read the initial code file to identify the individual initial submodules within it;
[0083] Rewrite each of the initial submodules using the Rust language;
[0084] Create an API interface for each rewritten initial submodule to obtain each independent submodule;
[0085] Generate a first code file corresponding to each of the aforementioned independent submodules.
[0086] Specifically, besides rewriting the initial submodules using Rust, they can also be rewritten using languages such as C++. This embodiment does not impose any restrictions on this, thereby achieving the purpose of language portability and ensuring functional consistency. The first code file can correspond to a WASM module, which refers to a binary code unit compiled using WebAssembly technology that can be efficiently executed in environments such as browsers and Node.js.
[0087] The process of establishing the local dependency graph corresponding to each of the independent sub-modules in this application is described in detail below.
[0088] Create individual threads;
[0089] Load each of the aforementioned threads and instantiate the independent submodules corresponding to each of the aforementioned threads to obtain each target thread;
[0090] Determine the dependency tree corresponding to the initial code file;
[0091] The dependency tree is split into subtrees for parallel processing;
[0092] For each target thread, the target thread initiates a task request to the main thread, so that the main thread can determine a corresponding subtree from each of the subtrees as the target subtree corresponding to the target thread;
[0093] The target subtree is assigned to the target thread so that the target thread can load the corresponding independent subtree to generate a local dependency graph.
[0094] Specifically, this step can begin by preparing the environment and tasks for parallel analysis in the main thread. The main thread starts from the project's entry file (such as src / main.js or src / index.ts) and performs a preliminary, quick dependency scan. This preliminary scan is only to obtain the top-level dependency structure, with the purpose of splitting tasks, without performing in-depth analysis.
[0095] Then, a certain number of target threads are created. The number of target threads can be configured according to the number of CPU cores of the current device. For example, on an 8-core CPU, in order to leave more resources for the main thread, 7 target threads, i.e. 7 Workers, are created.
[0096] In the process of splitting the dependency tree into subtrees for parallel processing, it can be split by package, such as treating each top-level package in node_modules (such as react, lodash) as an independent subtree, because there are usually no cross dependencies between different packages, so this can ensure accuracy; it can also be split by functional module, if the initial code file is very large, it can be split according to different routes or functional modules.
[0097] Finally, the subtrees are mapped to the target threads so that the target threads can load the corresponding independent subtrees to generate a local dependency graph.
[0098] The steps for creating each target thread in the above process may include:
[0099] Detect the number of CPU cores in the current device;
[0100] Get the main thread processing speed;
[0101] The number of CPU cores and the main thread processing speed are standardized to obtain a first standard value and a second standard value.
[0102] The target score is obtained by weighted summation of the first and second standard values;
[0103] A first threshold is set based on the target score;
[0104] Create the target number of threads corresponding to the first threshold.
[0105] Specifically, to ensure the normal operation and efficiency of the main thread and each target thread after creation, the number of target threads needs to be set according to the number of CPU cores on the current device. First, the number of CPU cores is obtained, and then the processing speed of the main thread is obtained, which is an important indicator of the main thread's processing performance. Then, a result is calculated based on these two standards. However, the number of CPU cores and the processing speed of the main thread do not belong to the same category of values, so they cannot be directly weighted and summed. Therefore, a unified standardization process is required to convert them into values on the same dimension (percentage system), and then a weighted sum is calculated to obtain a target score. This target score is used to set the first threshold. The formula for calculating the first threshold is: First threshold = Number of CPU cores × K. If the target score is in the range of 80~100, then K is 0.9; if the target score is in the range of 60~80, then K is 0.7; if the target score is in the range of 40~60, then K is 0.5; if the target score is below 40, then K is 0.3.
[0106] Optionally, the process of assigning the target subtree to the target thread so that the target thread can load the corresponding independent subtree to generate a local dependency graph can be implemented as follows:
[0107] Read the file content and file extension corresponding to the target subtree;
[0108] A parser is selected based on the file extension, and the parser is used to parse the file content into an abstract syntax tree;
[0109] Traverse each node in the abstract syntax tree to determine the unique identifier, the exported interface, and the dependencies between the nodes.
[0110] A local dependency graph corresponding to the independent submodule is generated based on the unique identifier, the exported interface, and the dependencies between the nodes.
[0111] Specifically, the above process uses file extensions to select parsers to ensure the accuracy of correspondence and parsing. Then, the file content is parsed to determine the sampled syntax tree. To construct a local dependency graph, it is necessary to determine the data structure definition of the abstract syntax tree, including module hashes, i.e., unique identifiers generated from the file content, APIs exposed by independent submodules, i.e., exported interfaces, and the dependency relationships between various nodes.
[0112] Therefore, when merging into a global dependency graph, it is necessary to ensure the correctness of the topological order in order to guarantee the accuracy of subsequent optimization caching.
[0113] Furthermore, after the above scheme is completed, shared memory communication can be achieved: a SharedArrayBuffer data channel is created between JavaScript and WASM. First, memory allocation is performed. The SharedArrayBuffer is initialized in JavaScript with a fixed size (e.g., 100MB) and passed to the WASM module. The WASM module accesses the shared memory directly through a pointer without data copying. Then, the local dependency graph is written to the shared memory in binary format. The WASM module fills the results into the specified location in the shared memory according to a predetermined format. Finally, after deducting serialization overhead, JavaScript directly parses the binary data in the shared memory through DataView and restores it to the dependency graph object.
[0114] The following embodiments provide a detailed explanation of the steps in this application for optimizing the first code file corresponding to each independent submodule using the global dependency graph.
[0115] Each exported interface is determined from the global dependency graph;
[0116] Determine if there are any unused export interfaces. If so, determine the first code file containing the unused export interface, remove the code corresponding to the unused export interface, and obtain the second code file.
[0117] The local variable names in the second code file are compressed, and all comments and whitespace characters are removed to obtain the third code file;
[0118] The third code file is standardized to obtain the fourth code file;
[0119] Calculate the hash value of the fourth code file, and select the first N bits of the hash value as the target hash;
[0120] The target hash is used to mark the third file to obtain the target code file.
[0121] Specifically, the code removal of the exported interface, local variable name compression, format standardization, and calculation of the target hash in the above process are all aimed at optimizing the first code file and reducing unnecessary resource consumption.
[0122] The local variable names, after compression, can be output in standard ESM format. The hash value can be calculated using SHA-256, with N set to 6, such as _vendor.abc123.js. These are then stored uniformly in the / _wcache / directory. Marking the third file using the target hash can be seen as creating the filename, thus obtaining the target code file.
[0123] Furthermore, the process of caching the target code file corresponding to each of the aforementioned independent submodules may include the following steps:
[0124] Obtain the original path of each independent submodule and the file path of the corresponding target code file;
[0125] For each of the aforementioned independent submodules, an index table is created based on the original path and file path of the independent submodule;
[0126] The index table of each of the independent sub-modules is cached separately.
[0127] Specifically, an index table is constructed for the target code file, with the structure: Map<original path→file path>, where the original path refers to the path of the first code file and the file path refers to the path of the target code file. Then, the index table is serialized into JSON and stored locally or on disk for persistence.
[0128] Subsequently, the ESM loader can be used for hijacking. First, the request is intercepted, and then resolved via import.meta.resolve or a custom method. <script type="module">拦截实现，并且仅劫持node_modules的ESM请求；然后重定向至缓存，根据模块名（如react）获取文件路径（如 / _wcache / _vendor.abc123.js），并修改import路径指向缓存文件；最后触发增量编译，生成新缓存并更新索引，并设置降级策略。
[0129] 更进一步地，优化缓存后构建变更检测树，监听package.json / lockfile变更生成依赖变更子树，标记受影响模块的污染状态，以触发局部重编译，降低缓存重建开销，即仅对污染子树启动编译，新缓存与旧版本并行存储，通过版本号隔离，在热更新时切换缓存版本，避免编译抖动。
[0130] 与图1所述的方法相对应，本发明实施例还提供了代码的优化缓存装置，用于对图1中方法的具体实现，本发明实施例提供的代码的优化缓存装置可以在计算机终端或各种移动设备中，结合图2，对代码的优化缓存装置进行介绍，如图2所示，该装置可以包括：
[0131] 拆解模块10，用于将待优化缓存的初始代码文件拆解为各个独立子模块对应的各个第一代码文件；
[0132] 局部依赖图谱建立模块20，用于建立与每一个所述独立子模块对应的局部依赖图谱；
[0133] 合并模块30，用于将各个所述独立子模块对应的局部依赖图谱进行合并，得到全局依赖图谱；
[0134] 优化模块40，用于利用所述全局依赖图谱，对每一个所述独立子模块对应的第一代码文件进行优化，得到目标代码文件；
[0135] 缓存模块50，用于将每一个所述独立子模块对应的目标代码文件进行缓存。
[0136] 从上述技术方案可以看出，本申请将待优化缓存的初始代码文件拆解为各个独立子模块对应的各个第一代码文件；建立与每一个所述独立子模块对应的局部依赖图谱；将各个所述独立子模块对应的局部依赖图谱进行合并，得到全局依赖图谱；利用所述全局依赖图谱，对每一个所述独立子模块对应的第一代码文件进行优化，得到目标代码文件；将每一个所述独立子模块对应的目标代码文件进行缓存。本申请通过首先对待优化缓存的初始代码文件进行拆解，这样就可以细小化初始代码文件，得到每一个独立子模块对应的第一代码文件，然后建立与每一个独立子模块对应的局部依赖图谱，分析出每一个独立子模块内部的依赖关系，然后再将分散的依赖关系进行合并，从而可以识别出独立子模块之间的交叉依赖、循环依赖、隐式依赖等等，这样后续就可以利用全局依赖图谱去对每一个独立子模块对应的第一代码进行精准的优化，防止遗漏独立子模块之间的关系，并针对每一个独立子模块实现细粒度缓存，实现高效快速的优化缓存，还可以加速后续的构建、测试、部署等流程。
[0137] 更进一步地，本申请实施例提供了一种代码的优化缓存设备。可选的，图3示出了代码的优化缓存设备的硬件结构框图，参照图3，代码的优化缓存设备的硬件结构可以包括：至少一个处理器01，至少一个通信接口02，至少一个存储器03和至少一个通信总线04。
[0138] 在本申请实施例中，处理器01、通信接口02、存储器03、通信总线04的数量为至少一个，且处理器01、通信接口02、存储器03通过通信总线04完成相互间的通信。
[0139] 处理器01可以是一个中央处理器CPU，或者是特定集成电路ASIC（ApplicationSpecific Integrated Circuit），或者是被配置成实施本发明实施例的一个或多个集成电路等。
[0140] 存储器03可能包含高速RAM存储器，也可能还包括非易失性存储器（non-volatilememory）等，例如至少一个磁盘存储器。
[0141] 其中，存储器存储有程序，处理器可调用存储器存储的程序，程序用于执行下述代码的优化缓存方法，包括：
[0142] 将待优化缓存的初始代码文件拆解为各个独立子模块对应的各个第一代码文件；
[0143] 建立与每一个所述独立子模块对应的局部依赖图谱；
[0144] 将各个所述独立子模块对应的局部依赖图谱进行合并，得到全局依赖图谱；
[0145] 利用所述全局依赖图谱，对每一个所述独立子模块对应的第一代码文件进行优化，得到目标代码文件；
[0146] 将每一个所述独立子模块对应的目标代码文件进行缓存。
[0147] 可选的，程序的细化功能和扩展功能可参照方法实施例中的代码的优化缓存方法的描述。
[0148] 本申请实施例还提供一种存储介质，该存储介质可存储有适于处理器执行的程序，在所述程序运行时控制所述存储介质所在的设备执行下述代码的优化缓存方法，包括：
[0149] 将待优化缓存的初始代码文件拆解为各个独立子模块对应的各个第一代码文件；
[0150] 建立与每一个所述独立子模块对应的局部依赖图谱；
[0151] 将各个所述独立子模块对应的局部依赖图谱进行合并，得到全局依赖图谱；
[0152] 利用所述全局依赖图谱，对每一个所述独立子模块对应的第一代码文件进行优化，得到目标代码文件；
[0153] 将每一个所述独立子模块对应的目标代码文件进行缓存。
[0154] 具体地，该存储介质可以是一种计算机可读存储介质，计算机可读存储介质可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。
[0155] 可选的，程序的细化功能和扩展功能可参照方法实施例中的代码的优化缓存方法的描述。
[0156] 另外，在本公开各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，直播设备，或者网络设备等)执行本公开各个实施例方法的全部或部分步骤。
[0157] 最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语"包括”、"包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句"包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0158] 本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。
[0159] 对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点一致的最宽的范围。< / script>
Claims
1. A code optimization caching method, characterized in that, include: The initial code file to be optimized is broken down into the first code file corresponding to each independent submodule; Establish a local dependency graph corresponding to each of the independent sub-modules; The local dependency graphs corresponding to each of the independent sub-modules are merged to obtain the global dependency graph; Using the global dependency graph, the first code file corresponding to each independent submodule is optimized to obtain the target code file; The target code file corresponding to each of the independent sub-modules is cached.
2. The method according to claim 1, characterized in that, The process of breaking down the initial code file to be optimized into individual first code files corresponding to each independent sub-module includes: Read the initial code file to identify the individual initial submodules within it; Rewrite each of the initial submodules using the Rust language; Create an API interface for each rewritten initial submodule to obtain each independent submodule; Generate a first code file corresponding to each of the aforementioned independent submodules.
3. The method according to claim 1, characterized in that, The establishment of a local dependency graph corresponding to each of the independent sub-modules includes: Create individual threads; Load each of the aforementioned threads and instantiate the independent submodules corresponding to each of the aforementioned threads to obtain each target thread; Determine the dependency tree corresponding to the initial code file; The dependency tree is split into subtrees for parallel processing; For each target thread, the target thread initiates a task request to the main thread, so that the main thread can determine a corresponding subtree from each of the subtrees as the target subtree corresponding to the target thread; The target subtree is assigned to the target thread so that the target thread can load the corresponding independent subtree to generate a local dependency graph.
4. The method according to claim 3, characterized in that, The creation of each target thread includes: Detect the number of CPU cores in the current device; Get the main thread processing speed; The number of CPU cores and the main thread processing speed are standardized to obtain a first standard value and a second standard value. The target score is obtained by weighted summation of the first and second standard values; A first threshold is set based on the target score; Create the target number of threads corresponding to the first threshold.
5. The method according to claim 3, characterized in that, Assigning the target subtree to the target thread so that the target thread can load the corresponding independent subtree to generate a local dependency graph includes: Read the file content and file extension corresponding to the target subtree; A parser is selected based on the file extension, and the parser is used to parse the file content into an abstract syntax tree; Traverse each node in the abstract syntax tree to determine the unique identifier, the exported interface, and the dependencies between the nodes. A local dependency graph corresponding to the independent submodule is generated based on the unique identifier, the exported interface, and the dependencies between the nodes.
6. The method according to claim 1, characterized in that, The step of optimizing the first code file corresponding to each independent submodule using the global dependency graph to obtain the target code file includes: Each exported interface is determined from the global dependency graph; Determine if there are any unused export interfaces. If so, determine the first code file containing the unused export interface, remove the code corresponding to the unused export interface, and obtain the second code file. The local variable names in the second code file are compressed, and all comments and whitespace characters are removed to obtain the third code file; The third code file is standardized to obtain the fourth code file; Calculate the hash value of the fourth code file, and select the first N bits of the hash value as the target hash; The target hash is used to mark the third file to obtain the target code file.
7. The method according to any one of claims 1 to 6, characterized in that, The step of caching the target code file corresponding to each of the independent sub-modules includes: Obtain the original path of each independent submodule and the file path of the corresponding target code file; For each of the aforementioned independent submodules, an index table is created based on the original path and file path of the independent submodule; The index table of each of the independent sub-modules is cached separately.
8. A code optimization caching device, characterized in that, include: The decomposition module is used to decompose the initial code file to be optimized into each first code file corresponding to each independent sub-module; A local dependency graph building module is used to build a local dependency graph corresponding to each of the independent sub-modules. The merging module is used to merge the local dependency graphs corresponding to each of the independent sub-modules to obtain a global dependency graph. An optimization module is used to optimize the first code file corresponding to each independent submodule using the global dependency graph to obtain the target code file; The caching module is used to cache the target code files corresponding to each of the independent sub-modules.
9. A code optimization caching device, characterized in that, Including memory and processor; The memory is used to store programs; The processor is configured to execute the program to implement the steps of the code optimization caching method as described in any one of claims 1-7.
10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the code optimization caching method as described in any one of claims 1-7.