Method for dynamically adjusting code sub-library and electronic device

Abstract

This disclosure relates to a method and electronic device for dynamically adjusting code sub-libraries. The method is applied to an electronic device with multiple sub-libraries, and includes: obtaining call statistics for each associated module that has a call relationship with a target sub-module; calculating a comprehensive evaluation value for the target sub-module corresponding to each associated module based on the call statistics; and determining the target associated module within the multiple associated modules based on the comprehensive evaluation value, and configuring the target sub-module in the target sub-library corresponding to the target associated module in the multiple sub-libraries. This disclosure dynamically adjusts the position of the sub-module in the sub-libraries by quantifying and evaluating the call relationships between modules, so that when the processor runs the target associated module, the target sub-module is loaded into the execution area along with the target sub-library, thereby reducing the number of loading operations across sub-libraries and improving the system performance of the electronic device.

Description

Technical Field

[0001] This disclosure relates to the field of storage management technology, and in particular to a method and electronic device for dynamically adjusting code partitioning. Background Technology

[0002] Code banking is a common technique for expanding program storage space, primarily used to address the limitation of standard address space in running larger programs. In this architecture, the program execution space is typically divided into two parts: a common area for storing permanently resident programs, and a bank area for storing non-resident program code. Because the processor's address space is limited, the program code in the bank area does not reside simultaneously in the runtime memory; instead, the corresponding bank is loaded into the program execution area according to the needs of the currently running program.

[0003] However, existing code partitioning technologies have certain limitations. Typically, functional modules are statically allocated to specific partitions. For example, main programs such as garbage collection and wear leveling modules reside in different partitions, while sub-modules commonly called by multiple main programs (such as data copying units) are fixed in a particular partition. When a main program in the first partition needs to call a sub-module in the second partition, the system must first unload the first partition, load the second partition, execute the sub-module, and then reload the first partition. This frequent cross-partitioning call leads to a large number of bank loads, consuming system resources and increasing processing latency. Furthermore, the call frequency of functional modules changes at different stages of an electronic device's lifecycle (e.g., early and late stages), and a statically fixed partitioning layout cannot adapt to these changes, resulting in performance degradation at specific stages. Summary of the Invention

[0004] In view of this, this disclosure provides a method and electronic device for dynamically adjusting code sharding, which adjusts the storage location of sub-modules by dynamically evaluating the calling relationship between modules, so as to solve the problem of frequent cross-sharding calls and excessive loading times caused by static sharding layout in the prior art, which affects the performance of the device.

[0005] One or more embodiments of this disclosure provide a method for dynamically adjusting code sub-libraries, applied to an electronic device. The electronic device has multiple sub-libraries, each storing program code for a corresponding module. A target sub-module has a calling relationship with multiple associated modules within the multiple modules, and the target sub-module can be configured in any of the multiple sub-libraries. The method includes: obtaining call statistics for each associated module that has a calling relationship with the target sub-module; calculating a comprehensive evaluation value for the target sub-module corresponding to each associated module based on the call statistics; and determining a target associated module within the multiple associated modules based on the comprehensive evaluation value, and configuring the target sub-module in the target sub-library corresponding to the target associated module in the multiple sub-libraries.

[0006] One or more embodiments of this disclosure provide an electronic device, including a memory and a processor. The memory has multiple sub-libraries, each sub-library storing program code for a corresponding module. A target sub-module has a calling relationship with multiple associated modules within the multiple modules, and the target sub-module can be configured in any of the multiple sub-libraries. The processor is coupled to the memory and has an execution region limited by the address space size, allowing only a portion of the multiple sub-libraries to be loaded and executed at any given time. The processor is configured to perform the following operations: acquire call statistics for each associated module that has a calling relationship with the target sub-module; calculate a comprehensive evaluation value for the target sub-module corresponding to each associated module based on the call statistics; and determine a target associated module within the multiple associated modules based on the comprehensive evaluation value, and configure the target sub-module in the target sub-library corresponding to the target associated module in the multiple sub-libraries, such that when the processor runs the target associated module, the target sub-module is loaded into the execution region along with the target sub-library.

[0007] Based on the above, the code partitioning dynamic adjustment method and electronic device provided in this disclosure, by acquiring the call statistics of each associated module to the target submodule and calculating a comprehensive evaluation value, can quantitatively reflect which associated module is most dependent on the target submodule in the current system operating state. Configuring the target submodule into the target partition where the target associated module resides based on this comprehensive evaluation value can achieve a "co-loading" technical effect. Specifically, when the processor needs to run the target associated module, since the target submodule is already located in the same partition, it will be loaded into the restricted execution area along with the target partition. This mechanism avoids the processor having to perform additional partition switching and loading operations to call the target submodule during the execution of the target associated module, thereby reducing the frequency of partition loading, lowering system input / output (I / O) overhead, and improving the code execution efficiency of the electronic device. Furthermore, since the adjustment is based on real-time statistical data, even if the electronic device enters different operating stages (e.g., from the initial stage to the aging stage), causing changes in the activity of each associated module, this disclosure can adaptively readjust the position of the target sub-module to ensure that the electronic device can maintain better performance throughout its entire life cycle. Attached Figure Description

[0008] Figure 1A This is a block diagram of an electronic device according to an embodiment of the present disclosure;

[0009] Figure 1B This is a schematic diagram illustrating a library loading mechanism and address space limitations according to an embodiment of this disclosure;

[0010] Figure 2 This is a flowchart illustrating a method for dynamically adjusting code partitioning according to an embodiment of this disclosure;

[0011] Figure 3 This is a schematic diagram illustrating the inter-module calling relationship and the undetermined location of the target sub-module according to an embodiment of this disclosure;

[0012] Figure 4 This is a hierarchical call relationship diagram of associated modules and target sub-modules shown according to an embodiment of this disclosure;

[0013] Figure 5 This is a detailed flowchart illustrating a code library dynamic adjustment method that includes a comprehensive evaluation value calculation and parallel processing mechanism, according to an embodiment of this disclosure;

[0014] Figure 6 This is a schematic diagram illustrating the calculation of the first weighting parameter (call frequency information) according to an embodiment of the present disclosure;

[0015] Figure 7This is a schematic diagram illustrating the calculation of the second weighting parameter (calling associated information) according to an embodiment of this disclosure;

[0016] Figure 8 This is a schematic diagram illustrating the calculation of comprehensive evaluation values ​​and the determination of target sub-databases according to an embodiment of this disclosure;

[0017] Figure 9 This is a comparative schematic diagram showing the dynamic adjustment in response to changes in operating state before and after, according to an embodiment of the present disclosure;

[0018] Figure 10 This is a timing diagram illustrating the dynamic adjustment of triggering timing according to an embodiment of the present disclosure;

[0019] Figure 11 This is a timing diagram illustrating the interaction between the processor, running memory, and memory according to an embodiment of the present disclosure. Detailed Implementation

[0020] Reference will now be made in detail to exemplary embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Wherever possible, the same component reference numerals are used in the drawings and description to denote the same or similar parts.

[0021] Reference Figure 1A In one embodiment, the electronic device 100 includes a processor 110 and a memory 120. The memory 120 has multiple sub-databases, namely sub-database 0 (BK0), sub-database 1 (BK1), sub-database 2 (BK2) to sub-database N (BKN), and the multiple sub-databases are used to store program code corresponding to multiple modules.

[0022] In one embodiment, the electronic device 100 is a solid-state drive (SSD). The processor 110 is an embedded processor within the storage controller of the SSD, the runtime memory 130 is static random access memory (SRAM) within the storage controller, and the memory 120 is flash memory (such as NAND flash memory) within the SSD. Multiple library-specific program codes are stored as part of the firmware in the memory 120. Since the capacity of the runtime memory 130 is much smaller than the total amount of program code in all libraries in the memory 120, the processor 110 needs to perform a library loading operation during runtime to load the required library-specific program code from the memory 120 to the library loading area 132 of the runtime memory 130 before execution.

[0023] Solid-state drive (SSD) firmware typically includes multiple functional modules, such as garbage collection, wear leveling, error handling, and host command processing modules. The program code for each functional module is stored in a corresponding sub-library within the memory 120. Since the processor 110 in the storage controller has limited memory capacity, it cannot simultaneously accommodate the program code of all functional modules. Therefore, a code sub-library mechanism is used to manage the program code. However, this disclosure does not limit the specific type of electronic device 100. In other embodiments, electronic device 100 may also be an embedded multimedia card (eMMC) controller, a universal flash memory (UFS) controller, a microcontroller (MCU), or other electronic devices employing a code sub-library mechanism.

[0024] Processor 110 is connected to memory 120 and has running memory 130. Running memory 130 includes a common area 131 and a library loading area 132. Common area 131 is used to store the resident main program code. In the above embodiment of solid-state drive, the main program code stored in common area 131 is, for example, the core program of the Flash Translation Layer (FTL). The core program resides in running memory 130 continuously during the operation of electronic device 100 without switching. Library loading area 132 is limited by the address space size of processor 110 or the physical capacity of running memory 130, and can only load and run a portion of multiple libraries at the same time. In other words, the capacity of library loading area 132 is less than the total amount of program code of all libraries in memory 120. Therefore, when processor 110 needs to execute modules in different libraries, it needs to load the program code of the corresponding library into library loading area 132 through library loading operation. In the above-described solid-state drive embodiment, the running memory 130 is, for example, the static random access memory (SRAM) inside the storage controller, and its capacity is typically in the range of tens to hundreds of kilobytes. However, the total amount of program code in all libraries in the memory 120 may reach hundreds of kilobytes or even more. Therefore, there is a situation where the library loading area 132 cannot accommodate all libraries at the same time.

[0025] Specifically, when processor 110 needs to execute program code from a certain library, processor 110 must load the program code of that library from memory 120 into the library loading area 132 before it can run. As shown by arrow A11, processor 110 loads the program code of library 1 (BK1) from memory 120 into the library loading area 132. When processor 110 subsequently needs to execute program code from another library (e.g., library 2 (BK2)), processor 110 needs to perform the library loading operation again, overwriting the program code of library 2 (BK2) into the library loading area 132. Each library loading operation consumes a certain amount of time and processing resources (I / O Overhead), therefore the number of library loading operations directly affects the operating performance of electronic device 100.

[0026] In one embodiment, the processor 110 may be, for example, any of a microcontroller (MCU), digital signal processor (DSP), embedded processor, central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), neural processing unit (NPU), or other programmable general-purpose or special-purpose processor, or a combination of the above devices; this disclosure does not limit this. In one embodiment, some or all of the functions of the processor 110 may be implemented by hardware circuitry, for example, by using an application-specific integrated circuit to collect statistical data and calculate comprehensive evaluation values, thereby improving computational speed. The running memory 130 may be any of the following: Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Tightly Coupled Memory (TCM), or Register File within the processor 110, or a combination of the above storage media. This disclosure does not limit the specific storage media type of the running memory 130, as long as its capacity is limited and cannot simultaneously accommodate all the program code in the memory 120, thus requiring a code partitioning mechanism.

[0027] The memory 120 is used to persistently store program code for multiple libraries. In one embodiment, the memory 120 may be any of the following: read-only memory (ROM), programmable read-only memory (PROM), flash memory, electrically erasable programmable read-only memory (EEPROM), NOR flash memory, NAND flash memory, or other types of non-volatile memory, without limitation herein. In another embodiment, the memory 120 may also be volatile memory, for example, when the program code of the electronic device 100 is loaded into the memory 120 by an external host system during the boot phase, the memory 120 may be random access memory (RAM). In one embodiment, the memory 120 may be integrated with the processor 110 on the same chip, for example, implemented as a system on chip (SoC); in another embodiment, the memory 120 may be a chip component independent of the processor 110 and connected to the processor 110 via a bus interface. This disclosure does not limit the hardware topology relationship between the memory 120 and the processor 110.

[0028] In one embodiment, the electronic device 100 is an embedded storage controller, such as an embedded multi-media card (eMMC) controller, a universal flash storage (UFS) controller, or a solid state drive (SSD) controller, but this disclosure is not limited thereto.

[0029] exist Figure 1A In the illustrated embodiment, the RAM 130 is described as a component independent of the memory 120. However, this disclosure is not limited thereto. In one embodiment, the RAM 130 may be integrated with the memory 120 on the same chip; in another embodiment, the RAM 130 may be composed of a combination of various different types of storage media. This disclosure does not limit the specific hardware configuration and connection method of the RAM 130 and the memory 120.

[0030] Reference Figure 1BThis demonstrates the operational logic of the electronic device 100 under a code library partitioning mechanism. In one embodiment, the available space of the running memory 130 (serving as the execution area of ​​the processor 110) is limited by the address space size of the processor 110; therefore, the running memory 130 cannot simultaneously accommodate the program code of all libraries in the memory 120. The running memory 130 is divided into a common area 131 and a library loading area 132. The common area 131 is used to store fixed programs, i.e., program code that continuously resides in the running memory 130 without switching during the operation of the electronic device 100. The library loading area 132 is a switchable area, allowing only a portion of the libraries from multiple libraries to be loaded and executed at any given time.

[0031] In one embodiment, the memory 120 stores multiple sub-banks, including sub-bank 0, sub-bank 1, sub-bank 2, sub-bank 3, and sub-bank 4. Each sub-bank stores program code corresponding to multiple modules. When the processor 110 needs to execute the program code of a certain module, as shown by arrow A12, the processor 110 performs a load operation, loading the program code of the corresponding sub-bank (e.g., sub-bank 2) from the memory 120 into the sub-bank loading area 132 for execution. If the processor 110 subsequently needs to execute another module in sub-bank 3, the processor 110 performs another load operation, overwriting the program code of sub-bank 3 with the program code in the sub-bank loading area 132; this constitutes a sub-bank switch.

[0032] Since the sub-library loading area 132 can only load and run a portion of the sub-libraries at any given time, the number of loading operations increases when the processor 110 frequently switches between modules in different sub-libraries. Each loading operation consumes a certain amount of time and processing resources (e.g., I / O bandwidth and CPU cycles). Therefore, the configuration of the program code of different modules in each sub-library directly affects the triggering frequency of loading operations, thereby affecting the operating performance of the electronic device 100. The dynamic adjustment method of code sub-libraries in subsequent embodiments of this disclosure aims to improve system efficiency by optimizing the configuration position of the target sub-module in multiple sub-libraries and reducing the number of loading (target sub-module) operations caused by sub-library switching.

[0033] Reference Figure 2 The processor 110 executes a method for dynamically adjusting code partitioning, the method including steps S210 to S240.

[0034] In step S210, the processor 110 determines the target submodule that has a calling relationship with multiple associated modules within the multiple modules.

[0035] Specifically, in one embodiment, the processor 110 can traverse the program code of multiple modules stored in multiple sub-libraries in the memory 120, analyze the function call relationship (Call Graph) between the modules, identify the sub-module that is called by multiple modules, and determine it as the target sub-module.

[0036] For example, processor 110 identifies sub-modules that are jointly called by multiple related modules in their respective execution flows by parsing the symbol tables, relocation tables, or linking information of each module. In one embodiment, processor 110 may identify such a sub-module, then processor 110 determines the sub-module as the target sub-module and executes subsequent steps S220 to S240 for the target sub-module.

[0037] In another embodiment, the processor 110 may identify multiple such sub-modules, i.e., multiple sub-modules that are jointly called by at least two associated modules. In this case, the processor 110 independently executes steps S220 to S240 for each target sub-module, obtains the call statistics of each associated module for the target sub-module, calculates the corresponding comprehensive evaluation value, and configures the target sub-module in the corresponding target sub-library.

[0038] Taking solid-state drive firmware as an example, processor 110 may find that both the data copy submodule (CopyUnit) and the buffer management submodule (BufferManager) are jointly called by at least two related modules among the garbage collection (GC) module, wear leveling (WL) module, and error handling (ErrorHandle) module. In this case, processor 110 identifies the data copy submodule (CopyUnit) and the buffer management submodule (BufferManager) as target submodules and executes subsequent configuration decision processes on them respectively. Multiple related modules refer to those modules among multiple modules that have a calling relationship with the target submodules, and the target submodules can be physically configured in any of multiple database partitions.

[0039] In step S220, the processor 110 obtains the call statistics of the target submodule corresponding to each associated module. The call statistics are used to quantify the interaction behavior between each associated module and the target submodule.

[0040] In one embodiment, the call statistics specifically include call frequency information for each associated module and call association information between each associated module and the target sub-module. The call frequency information reflects the activity level of each associated module within a certain statistical period, while the call association information reflects the degree to which the target sub-module is depended upon in a single execution flow of each associated module. The processor 110 can collect call statistics by recording the call events of each associated module during operation using hardware counters or software instrumentation.

[0041] In step S230, the processor 110 calculates the comprehensive evaluation value of the target sub-module corresponding to each associated module based on the call statistics.

[0042] In one embodiment, the comprehensive evaluation value is a quantitative indicator obtained by integrating information from multiple dimensions in the call statistics, and is used to characterize the comprehensive call tightness between each associated module and the target sub-module.

[0043] In one embodiment, the comprehensive evaluation value is calculated based on a first weighted parameter and a second weighted parameter, wherein the first weighted parameter is determined based on call frequency information, and the second weighted parameter is determined based on call association information. The specific calculation methods for the first and second weighted parameters will be discussed in subsequent embodiments. Figures 5 to 7 Further explanation.

[0044] In step S240, the processor 110 determines the target associated module within multiple associated modules based on the comprehensive evaluation value, and configures the target sub-module in the target sub-database corresponding to the target associated module in multiple sub-databases.

[0045] Specifically, in one embodiment, the target associated module is the associated module corresponding to the one with the highest comprehensive evaluation value among multiple associated modules. The processor 110 compares the comprehensive evaluation values ​​corresponding to each associated module, selects the associated module with the highest comprehensive evaluation value as the target associated module, and physically or logically configures the program code of the target sub-module in the sub-library corresponding to the target associated module. Thus, when the processor 110 subsequently runs the target associated module, the target sub-module will be loaded into the sub-library loading area 132 along with the target sub-library, so that the processor 110 does not need to perform additional sub-library loading operations when calling the target sub-module, thereby reducing I / O overhead.

[0046] It is worth mentioning that, in another embodiment, the method further includes: in response to changes in the operating state of the electronic device 100 (e.g., from an idle state to a high-load state, or from the initial stage of the device to an aging stage), the processor 110 re-acquires the call statistics of the target sub-module corresponding to each associated module, so as to dynamically adjust the library configuration of the target sub-module. That is, during the operation of the electronic device 100, the processor 110 can repeatedly execute steps S220 to S240, so that the library configuration of the target sub-module can be adaptively updated as the operating state of the electronic device 100 changes.

[0047] In one embodiment, the "configuration" operation in step S240 can be implemented by modifying the address mapping table or bank descriptor in memory 120. Once the target bank is determined, processor 110 updates the metadata of the file system or firmware manager, remapping the logical address of the target submodule to the physical address range of the target bank. During the next bank loading operation, the Direct Memory Access (DMA) controller will move the target bank containing the target submodule to the bank loading area 132 according to the updated mapping.

[0048] Reference Figure 3 In one embodiment, taking the application scenario of an embedded storage controller as an example, the process of the processor 110 determining the target sub-module in step S210 is specifically described. For example, as shown in Table T31, the current configuration relationship between multiple modules in the electronic device 100 and each sub-database is as follows: the firmware translation layer (FTL) is the main program, and its program code is configured to run residently in the common area 131; the garbage collection (GC) module is an associated module, and its program code is configured in sub-database 0 (Bank 0); the wear leveling (WL) module is an associated module, and its program code is configured in sub-database 1 (Bank 1); the error handling (ErrorHandle) module is an associated module, and its program code is configured in sub-database 2 (Bank 2).

[0049] As shown in the dashed box TSM, the data copy submodule (CopyUnit) is identified as the target submodule. As indicated by arrow A31, the three associated modules—GC, WL, and ErrorHandle—call the data copy submodule (CopyUnit) within their respective execution flows, meaning there is a clear calling relationship between multiple associated modules and the target submodule. Since the data copy submodule (CopyUnit) is simultaneously called by three associated modules located in different databases, the processor 110 determines the data copy submodule (CopyUnit) as the target submodule in step S210.

[0050] As indicated by the "Configuration location to be determined (?)" mark in the target submodule TSM, the data copy submodule (CopyUnit) can be physically configured in any of the database shards 0, 1, or 2; that is, the target submodule can be configured in any of the multiple database shards. However, configuring the data copy submodule (CopyUnit) in different database shards will result in different database loading operation frequencies. For example, if the data copy submodule (CopyUnit) is configured in database 0, the GC module's call to the data copy submodule (CopyUnit) is an "intra-database call," requiring no database loading operation; however, the WL module and ErrorHandle module's call to the data copy submodule (CopyUnit) is a "cross-database call," requiring a switch from their respective databases to database 0, thus triggering additional database loading operations. Therefore, determining the optimal configuration location of the data copy submodule (CopyUnit) based on actual operating conditions is the core problem to be solved in subsequent steps S220 to S240.

[0051] Reference Figure 4 In one embodiment, the hierarchical calling architecture of each module in the electronic device 100 is further described. The main program MP is the firmware conversion layer (FTL), and its program code is configured in the common area 131, residing in the running memory 130 during the operation of the electronic device 100. As the core scheduler of the system, the main program MP, during execution, calls the associated modules RM0, RM1, and RM2 in the sub-database loading area according to the real-time operating requirements of the electronic device 100. Among them, associated module RM0 is the garbage collection (GC) module, and its program code is configured in sub-database 0 (Bank 0); associated module RM1 is the wear leveling (WL) module, and its program code is configured in sub-database 1 (Bank 1); associated module RM2 is the error handling (ErrorHandle) module, and its program code is configured in sub-database 2 (Bank 2).

[0052] In one embodiment, the operating mechanism of the main program MP (Firmware Translation Layer (FTL)) scheduling various associated modules is further explained. The Firmware Translation Layer (FTL), as the core scheduler of the electronic device 100, resides in the common area 131 and is responsible for receiving read and write commands from the external host and scheduling various associated modules to perform corresponding operations based on the current operating status of the electronic device 100. For example, when the available storage space in the memory 120 is lower than a preset threshold, the Firmware Translation Layer (FTL) calls the associated module RM0 (GC module) to perform garbage collection to release storage space; when the difference in the number of erase / write cycles of various storage areas in the memory 120 exceeds a preset range, the Firmware Translation Layer (FTL) calls the associated module RM1 (WL module) to perform wear leveling to balance the lifespan of each storage area; when a data verification error is detected in the memory 120, the Firmware Translation Layer (FTL) calls the associated module RM2 (ErrorHandle module) to perform error handling to restore data integrity. In the early stages of operation of the electronic device 100, due to the ample available space in the memory 120, the garbage collection operation is triggered frequently. At this time, the call frequency of the associated module RM0 (GC module) accounts for a relatively large proportion among the various associated modules. As the operating time of the electronic device 100 increases, the wear and tear on the storage medium gradually increases, and the trigger frequency of wear leveling and error handling operations rises accordingly. At this time, the call frequency of associated modules RM1 (WL module) and RM2 (ErrorHandle module) increases, while the call frequency of associated module RM0 (GC module) relatively decreases.

[0053] like Figure 4 As indicated by the dashed arrows, associated modules RM0, RM1, and RM2 call the target submodule TSM within their respective execution flows, such as the data copying submodule (CopyUnit). Specifically, when RM0 performs garbage collection to reclaim invalid blocks, it calls the target submodule TSM to perform data migration of valid pages; similarly, when RM1 performs wear leveling to balance block erase / write cycles, it calls the target submodule TSM to migrate hot and cold data blocks; and when RM2 performs error handling, it also calls the target submodule TSM to copy data from the abnormal area to the normal area. Therefore, all three associated modules RM0, RM1, and RM2 have a substantial calling relationship with the target submodule TSM.

[0054] Since associated modules RM0, RM1, and RM2 are configured in different databases, and the target submodule TSM, as a continuous piece of program code, can only be physically configured in one of these databases, when the target submodule TSM is configured in the database corresponding to a certain associated module, the processor 110 needs to perform a database loading operation to switch to the database where the target submodule TSM resides when other associated modules call the target submodule TSM. For example, if the target submodule TSM is configured in database 0 corresponding to associated module RM0, then both associated modules RM1 and RM2 need to trigger a cross-database loading operation when calling the target submodule TSM. By obtaining call statistics and calculating comprehensive evaluation values ​​in subsequent steps S220 to S240, the processor 110 can determine which database corresponding to the associated module the target submodule TSM should be configured in, thereby minimizing the total number of database loading operations triggered by calling the target submodule TSM and optimizing the overall system performance.

[0055] In one embodiment, this hierarchical call relationship can be identified during the compilation phase by a static code analysis tool, or dynamically identified by sampling the function call stack at runtime. Figure 4 The architecture shown is only an example. In actual systems, there may be more layers of module call relationships. However, as long as there is a structure in which "multiple parent modules compete to call the same child module", the dynamic adjustment method disclosed herein is applicable.

[0056] Reference Figure 5 It further explains the process of obtaining statistical data, calculating comprehensive evaluation values, and determining target sub-databases in steps S220 to S240. Figure 5 The process shown includes steps S510 to S580.

[0057] In step S510, the processor 110 obtains the call statistics of the target submodule TSM corresponding to each associated module.

[0058] In one embodiment, the call statistics specifically include call frequency information for each associated module and call association information between each associated module and the target submodule TSM. The call frequency information reflects the activity level of each associated module during the operation of the electronic device 100 (i.e., "who is busier"), and the call association information reflects the degree to which the target submodule TSM is relied upon in the execution flow of each associated module (i.e., "who needs the target submodule more").

[0059] In one embodiment, the processor 110 collects call statistics via software. Specifically, the processor 110 inserts counting instructions at the entry function of each associated module. Whenever the main program (e.g., the firmware transition layer (FTL)) calls an associated module, the counting instruction is executed, and the corresponding call counter value is incremented by one. Similarly, the processor 110 inserts counting instructions at the call points of each associated module that call the target submodule TSM to record the number of times each associated module calls the target submodule TSM in a single execution flow. The counting instructions can be automatically inserted by the compiler during the compilation stage or manually added by the developer during the firmware development stage; this disclosure does not limit this.

[0060] In another embodiment, the processor 110 collects call statistics via hardware. For example, the processor 110 has an internal hardware performance counter that can count function call events within a specified address range without affecting the normal execution of the program. The processor 110 configures the entry addresses of each associated module and the entry address of the target submodule TSM within the monitoring range of the hardware performance counter, which automatically records the number of calls. Compared to the software method, the hardware method does not require additional counting instructions to be inserted into the program code, thus not occupying program code space, and is suitable for application scenarios with limited runtime memory (130).

[0061] After step S510, processor 110 may execute steps S521 and S522 in parallel or sequentially. In step S521, processor 110 calculates a first weighting parameter based on the call frequency information. In one embodiment, the first weighting parameter is the proportion of the number of calls to each associated module within a statistical period to the total number of calls to multiple associated modules within the statistical period.

[0062] Specifically, with Figure 3 Taking the associated modules RM0 (GC module), RM1 (WL module), and RM2 (ErrorHandle module) as an example, assuming that within a statistical period, associated module RM0 is called 700 times, associated module RM1 is called 0 times, and associated module RM2 is called 300 times, then the total number of calls to all associated modules within the statistical period is 1000 times. Therefore, the first weighted parameter of associated module RM0 is calculated to be 700 / 1000 = 70%, the first weighted parameter of associated module RM1 is 0 / 1000 = 0%, and the first weighted parameter of associated module RM2 is 300 / 1000 = 30%.

[0063] In step S522, the processor 110 calculates a second weighting parameter based on the call association information. The second weighting parameter is the proportion of the number of times each associated module calls the target submodule TSM in a single execution flow to the total number of times multiple associated modules call the target submodule TSM in their respective single execution flows.

[0064] Continuing the example above, suppose associated module RM0 calls the target submodule TSM (CopyUnit) 3 times in a single execution flow, associated module RM1 calls the target submodule TSM 2 times in a single execution flow, and associated module RM2 calls the target submodule TSM 5 times in a single execution flow. Then, the total number of times the multiple associated modules call the target submodule TSM in their respective single execution flows is 10. Therefore, the second weighted parameter of associated module RM0 is calculated to be 3 / 10 = 30%, the second weighted parameter of associated module RM1 is 2 / 10 = 20%, and the second weighted parameter of associated module RM2 is 5 / 10 = 50%.

[0065] In step S530, the processor 110 calculates the comprehensive evaluation value of the target submodule TSM corresponding to each associated module based on the product of the first weighting parameter and the second weighting parameter. That is, the comprehensive evaluation value is the product of the first weighting parameter and the second weighting parameter.

[0066] Continuing with the example above, the overall evaluation value of associated module RM0 is 70% × 30% = 0.21, the overall evaluation value of associated module RM1 is 0% × 20% = 0, and the overall evaluation value of associated module RM2 is 30% × 50% = 0.15.

[0067] In step S540, the processor 110 determines whether the largest comprehensive evaluation value is unique. If the largest comprehensive evaluation value is unique, then step S550 is executed; if the largest comprehensive evaluation value is not unique, that is, there are at least two related modules with the same comprehensive evaluation value and both are the maximum value (e.g., both are 0.21), then step S560 is executed to perform arbitration.

[0068] In step S550, when the largest comprehensive evaluation value is unique, the processor 110 determines the associated module corresponding to the largest comprehensive evaluation value as the target associated module. Furthermore, the processor 110 determines the sub-database corresponding to the target associated module as the target sub-database.

[0069] Continuing with the example above, since the comprehensive evaluation value of associated module RM0 is 0.21, which is the largest and unique, processor 110 determines associated module RM0 (GC module) as the target associated module and locks its corresponding shard 0 as the target shard for subsequent configuration.

[0070] In step S560, when at least two of the associated modules have the same comprehensive evaluation value and both are the maximum value, the processor 110 obtains the sub-database loading frequency data of the sub-databases corresponding to the at least two associated modules.

[0071] In one embodiment, the sub-library loading frequency data reflects the frequency at which each sub-library is loaded into the sub-library loading area 132 during the operation of the electronic device 100.

[0072] In step S570, the processor 110 compares the database loading frequency data corresponding to at least two associated modules and determines the database with the higher database loading frequency data as the target database. The technical principle is that a database with a higher database loading frequency means that it has a greater chance of being loaded into the database loading area 132 during runtime. Selecting this database as the target database increases the probability that the target submodule TSM will be "piggybacked" on the loading of this database, thereby more effectively reducing the additional database loading operations triggered by loading the target submodule TSM alone.

[0073] In step S580, the processor 110 performs a configuration operation based on the target sub-database determined in step S550 or step S570.

[0074] Specifically, in one embodiment, the processor 110 configures the program code of the target submodule TSM in the target sub-library. If the target submodule TSM is already located in the target sub-library, the status quo is maintained; if the target submodule TSM is currently located in another sub-library, it is migrated to the target sub-library, and the address mapping relationship in the memory 120 is updated so that subsequent calls to the target submodule TSM point to the target sub-library.

[0075] In the above embodiments, steps S521 and S522 are described as being executed in parallel. However, this disclosure is not limited thereto.

[0076] In one embodiment, the processor 110 may execute steps S521 and S522 sequentially, that is, calculate the first weighting parameter first and then calculate the second weighting parameter, or vice versa. The calculation order of the first weighting parameter and the second weighting parameter does not affect the calculation result of the final comprehensive evaluation value.

[0077] The step numbers and process order in the above embodiments are set for ease of explanation only and do not constitute a limitation on the execution order of each step. Provided that the logical dependencies between steps are not violated, some steps may be executed in different orders or in parallel.

[0078] exist Figure 5In the illustrated embodiment, the comprehensive evaluation value is illustrated by the product of the first weighted parameter and the second weighted parameter. However, this disclosure is not limited to this. In other embodiments, the comprehensive evaluation value can be obtained through other calculation methods that integrate call frequency information and call association information, as long as the calculation method can quantify the degree of comprehensive call association between each associated module and the target sub-module.

[0079] For example, in one embodiment, the comprehensive evaluation value can be obtained by weighted summation of a first weighted parameter and a second weighted parameter. Specifically, the processor 110 sets weight coefficients w1 and w2 for the first weighted parameter and the second weighted parameter, respectively. The comprehensive evaluation value is equal to w1 multiplied by the first weighted parameter plus w2 multiplied by the second weighted parameter. The values ​​of w1 and w2 satisfy w1 + w2 = 1 and w1 ≥ 0, w2 ≥ 0. For example, when w1 = 0.6 and w2 = 0.4, the processor 110 assigns a higher weight to the call frequency information, making associated modules with higher call frequencies have a greater influence in the comprehensive evaluation value; when w1 = 0.4 and w2 = 0.6, the processor 110 assigns a higher weight to the call association information, making associated modules with a higher dependence on the target submodule have a greater influence in the comprehensive evaluation value.

[0080] continue Figure 6 and Figure 7 The numerical example shown illustrates that, using a weighted summation method with w1=0.6 and w2=0.4, the overall evaluation value of the associated module RM0 (GC module) is 0.6×70%+0.4×30%=0.42+0.12=0.54, the overall evaluation value of the associated module RM1 (WL module) is 0.6×0%+0.4×20%=0+0.08=0.08, and the overall evaluation value of the associated module RM2 (ErrorHandle module) is 0.6×30%+0.4×50%=0.18+0.20=0.38. In this case, the overall evaluation value of the associated module RM0 is still the highest, compared to... Figure 8 The conclusions obtained by the product method shown are consistent, but the differences in the comprehensive evaluation values ​​between the related modules are different. The weighting coefficients w1 and w2 can be preset by the developers according to the application scenario of the electronic device 100, or can be adaptively adjusted by the processor 110 according to the historical configuration effect; this disclosure does not limit this.

[0081] In another embodiment, the comprehensive evaluation value can be calculated by introducing a third dimension of call statistics. For example, in addition to obtaining call frequency information and call association information, processor 110 also obtains the library loading time information of the corresponding library for each associated module. The library loading time information reflects the time required to load each library from memory 120 to the library loading area 132. Different libraries may require different loading times to reach the library loading area 132 due to differences in their program code size. Processor 110 incorporates the library loading time information as a third weighting parameter into the calculation of the comprehensive evaluation value, so that the comprehensive evaluation value not only reflects the call frequency and call association, but also reflects the difference in loading time corresponding to configuring the target submodule in different libraries. In this embodiment, processor 110 can use the product or weighted sum of the first weighting parameter, the second weighting parameter, and the third weighting parameter as the comprehensive evaluation value.

[0082] Reference Figure 6 The calculation process of the first weighted parameter in step S521 is explained in detail. In one embodiment, as shown in Table T61, the processor 110 counts the number of calls to each associated module within a statistical period, and the statistical result constitutes the "call frequency information" in the claim. In this embodiment, within the statistical period, associated module RM0 (GC module) is called 70 times, associated module RM1 (WL module) is called 0 times, and associated module RM2 (ErrorHandle module) is called 30 times. The processor 110 adds up these values ​​to obtain a total of 100 calls to the multiple associated modules within the statistical period.

[0083] As shown in formula box B60, the formula for calculating the first weighting parameter is: the number of times the associated module is called within the statistical period divided by the total number of times multiple associated modules are called within the statistical period. Accordingly, the processor 110 calculates the first weighting parameter for each associated module as follows: the first weighting parameter for associated module RM0 (GC module) is 70 / 100 = 70%, the first weighting parameter for associated module RM1 (WL module) is 0 / 100 = 0%, and the first weighting parameter for associated module RM2 (ErrorHandle module) is 30 / 100 = 30%. The first weighting parameter quantitatively reflects the calling activity of each associated module relative to other associated modules within the statistical period, and the sum of the first weighting parameters of the three associated modules is 100%.

[0084] like Figure 6As illustrated in the weighting diagram below, in the statistical period of this embodiment, the associated module RM0 (GC module) accounted for 70% of the call weight, the associated module RM2 (ErrorHandle module) accounted for 30% of the call weight, while the associated module RM1 (WL module) was not called during the statistical period, and its first weighting parameter was 0%. This distribution intuitively reflects that in the current operating phase of the electronic device 100, the execution frequency of garbage collection operations is higher than that of error handling operations, while wear leveling operations were not triggered during the statistical period. This weighting allocation based on actual operating data provides a macro-level decision-making basis for subsequently determining the optimal allocation of target sub-modules.

[0085] In one embodiment, the length of the statistical period can be set according to the usage scenario of the electronic device 100. For example, in the application scenario of an embedded storage controller, the statistical period can be set in units of "written data volume" (e.g., one cycle is defined as every 10GB of data written) or in units of "time" (e.g., every 24 hours of operation). In another embodiment, the processor 110 can record the number of calls by reading a hardware performance counter or by setting a software count variable at the entry point of each associated module. Furthermore, to avoid the impact of drastic fluctuations in historical data on decision stability, the processor 110 can also introduce a moving average algorithm when calculating the first weighted parameter, combining the weights of historical periods for smoothing.

[0086] exist Figure 6 In the illustrated embodiment, the statistical period is illustrated using a fixed time window as an example. However, this disclosure does not limit the specific length and setting method of the statistical period. In one embodiment, the statistical period can be set to a fixed time unit (e.g., one week); in another embodiment, the statistical period can be adaptively adjusted according to the usage frequency of the electronic device 100. Furthermore, the counting of call counts can be implemented using a hardware counter or a software counter, and this disclosure does not limit the specific implementation method.

[0087] Reference Figure 7The calculation process of the second weighted parameter in step S522 is explained in detail. In one embodiment, as shown in Table T71, the processor 110 obtains the number of times each associated module calls the target submodule TSM (CopyUnit) in a single execution flow. In this embodiment, associated module RM0 (GC module) needs to call the target submodule TSM 3 times in a complete garbage collection process; associated module RM1 (WL module) needs to call the target submodule TSM 2 times in a complete wear leveling process; and associated module RM2 (ErrorHandle module) needs to call the target submodule TSM 5 times in a complete error handling process. Summing these numbers, the total number of times the multiple associated modules call the target submodule TSM in their respective single execution flows is 10.

[0088] As shown in formula box B70, the formula for calculating the second weighting parameter is: the number of times the target submodule is called in a single process of the associated module divided by the total number of times it is called in a single process of multiple associated modules. Based on this, the processor 110 calculates the second weighting parameter for each associated module as follows: the second weighting parameter for associated module RM0 (GC module) is 3 / 10 = 30%, the second weighting parameter for associated module RM1 (WL module) is 2 / 10 = 20%, and the second weighting parameter for associated module RM2 (ErrorHandle module) is 5 / 10 = 50%. The second weighting parameter quantitatively reflects the degree of dependency (Dependency Degree) of the target submodule TSM within the internal logic of each associated module, and the sum of the second weighting parameters for the three associated modules is 100%.

[0089] like Figure 7 As shown in the weighting diagram below, the associated module RM2 (ErrorHandle module) calls the target submodule TSM the most times in a single execution flow, accounting for 50% of the weight; the associated module RM0 (GC module) accounts for 30%; and the associated module RM1 (WL module) accounts for 20%. It is worth noting that this distribution is consistent with... Figure 6 The distributions of the first weighted parameter shown are significantly different: Figure 6 The first weighted parameter of the associated module RM0 (GC module) is the highest (70%), while... Figure 7The second weighted parameter of the associated module RM2 (ErrorHandle module) is the highest (50%). This indicates that associated modules with high call frequency (high activity) are not necessarily associated modules with a high degree of dependence on the target submodule TSM (high dependence). If the database sharding location is determined solely based on call frequency, critical paths that, although run infrequently, are extremely dependent on submodules in each individual run may be overlooked. Therefore, in subsequent step S530, the first and second weighted parameters need to be calculated comprehensively to accurately assess the overall call association degree between each associated module and the target submodule TSM.

[0090] In one embodiment, the method for obtaining the "number of calls in a single execution flow" can be determined during the compilation phase through static code analysis. For example, the compiler analyzes the source code or intermediate code of each associated module to count the number of instructions called on the target submodule TSM within the function body of the associated module. In another embodiment, this data can also be obtained through offline performance analysis, i.e., during the development phase, standard test cases for each module are run using a simulator to count the average number of calls to the submodule, and the statistical results are pre-loaded into the firmware parameters of the electronic device 100.

[0091] exist Figure 6 and Figure 7 In the embodiments shown, the call counts of each associated module and the specific values ​​of the first weighting parameter and the second weighting parameter (e.g., 70%, 30%, 0%, etc.) are merely exemplary values ​​selected for illustrative purposes and do not constitute a limitation of this disclosure. In practical applications, the call counts and the values ​​of the weighting parameters will be determined according to the actual operating conditions of the electronic device 100 and may exhibit different distributions in different statistical periods.

[0092] Reference Figure 8 This document provides a detailed explanation of the calculation of the comprehensive evaluation value and the determination of the target sub-database in steps S530 to S580. In one embodiment, as shown in Table T81, the processor 110 executes step S530, which... Figure 6 The calculated first weighted parameter and Figure 7The calculated second weighting parameter is multiplied to obtain the comprehensive evaluation value of the target submodule TSM (CopyUnit) corresponding to each associated module. The specific calculation is as follows: the comprehensive evaluation value of associated module RM0 (GC module) is the product of the first weighting parameter 70% (0.7) and the second weighting parameter 30% (0.3), that is, 0.7 × 0.3 = 0.21; the comprehensive evaluation value of associated module RM1 (WL module) is the product of 0% and 20%, that is, 0; the comprehensive evaluation value of associated module RM2 (ErrorHandle module) is the product of 30% and 50%, that is, 0.3 × 0.5 = 0.15.

[0093] As shown by arrow A81 and box S81, after comparing the comprehensive evaluation values ​​of each associated module, the processor 110 determines that the comprehensive evaluation value of associated module RM0 (GC module), 0.21, is the largest and unique. Therefore, the processor 110 locks associated module RM0 (GC module) as the target associated module. It is worth noting that in this embodiment, although associated module RM2 (ErrorHandle module) calls the target submodule TSM the most times in a single execution flow (the second weighted parameter is as high as 50%, higher than GC's 30%), the overall call frequency of associated module RM2 within the statistical period is relatively low (the first weighted parameter is only 30%). After comprehensive evaluation, the comprehensive evaluation value of associated module RM0 (GC module) (0.21) is still higher than that of associated module RM2 (0.15). This result shows that the comprehensive evaluation value can balance the two dimensions of "macro-level call frequency" and "micro-level dependency", avoiding the local optimum trap that may be caused by relying on only a single dimension for configuration decisions.

[0094] As shown by arrow A82 and box S82, processor 110 determines the configuration strategy: configure the target submodule TSM (CopyUnit) in the target shard where the associated module RM0 (GC module) is located, i.e., shard 0. Figure 8 As shown below, in the pre-configuration state (dashed box B83), the location of the target submodule TSM (CopyUnit) is not yet determined. As indicated by arrow A83, after executing the configuration strategy, in the post-configuration state (solid box B84), the target submodule TSM (CopyUnit) is physically or logically configured in partition 0, and is stored in the same partition space as the program code of the associated module RM0 (GC module). Therefore, when the processor 110 subsequently runs the associated module RM0 (GC module) and calls the target submodule TSM (CopyUnit), the target submodule TSM will be loaded into the partition loading area 132 along with partition 0, achieving the effect of "loading along with" without needing to perform additional partition loading operations to call the submodule.

[0095] It should be noted that, in one embodiment, if the calculated comprehensive evaluation value is less than a preset threshold (e.g., 0.05), the processor 110 may choose not to perform any specific library binding, or place the target submodule TSM in the default spare library. This threshold mechanism can prevent frequent and meaningless configuration adjustments when all related modules have low demand for the submodule, thereby further saving system overhead.

[0096] Reference Figure 9 In one embodiment, the process by which the processor 110 dynamically adjusts the library configuration of the target submodule TSM (CopyUnit) after the operating state of the electronic device 100 changes is described.

[0097] As shown in step S90, in response to a change in the operating state of the electronic device 100, the processor 110 triggers a process to reacquire the call statistics of the target submodule TSM corresponding to each associated module. Taking an embedded storage controller as an example, when the electronic device 100 moves from the "early stage of operation" to the "late stage of operation," the number of bad blocks may increase as the wear and tear of the storage medium (such as NAND Flash) increases, causing a change in the call frequency of each associated module. After detecting a change in the operating state (e.g., the number of erase / write cycles exceeds a certain threshold), the processor 110 recalculates the call count of each associated module in the new statistical period to update the call frequency information.

[0098] As shown in Table T91, processor 110 recalculates the first weighted parameters and comprehensive evaluation values ​​of each associated module. During the later statistical period of operation, due to the relatively reduced or stable garbage collection pressure, the first weighted parameter of associated module RM0 (GC module) changes from... Figure 8 The percentage decreases from 70% to 20% (0.2); however, due to the surge in demand for wear leveling and error handling, the first weighted parameter of associated module RM1 (WL module) increases from 0% to 40% (0.4), and the first weighted parameter of associated module RM2 (ErrorHandle module) increases from 30% to 40% (0.4). It is worth noting that since the program code structure (i.e., function call relationships) of electronic device 100 itself has not changed, the number of times each associated module calls the target submodule TSM in a single execution flow remains constant; therefore, the second weighted parameter remains unchanged (i.e., RM0 is 0.3, RM1 is 0.2, and RM2 is 0.5). Accordingly, processor 110 recalculates the overall evaluation value of each associated module: associated module RM0 decreases to 0.06, associated module RM1 increases to 0.08, and associated module RM2 increases to 0.20.

[0099] As shown by arrow A91 and box S91, processor 110 compares the recalculated comprehensive evaluation values ​​and determines that the comprehensive evaluation value of associated module RM2 (ErrorHandle module), 0.20, is the maximum. Therefore, processor 110 re-locks associated module RM2 (ErrorHandle module) as the target associated module. Compared to Figure 8 The initial configuration shown is as follows (where the GC module is the winner). The target association module has changed in the later stages of the operation, which demonstrates the adaptive ability of the algorithm to changes in the system environment.

[0100] As shown by arrow A92 and box S92, processor 110 performs dynamic adjustment: migrating the target submodule TSM (CopyUnit) from the associated module RM0 (GC module) in partition 0 to the associated module RM2 (ErrorHandle module) in partition 2. Figure 9 As shown below, in the state before adjustment (dashed box B93), the target submodule TSM and the associated module RM0 are both located in partition 0. As indicated by arrow A93, after dynamic adjustment, in the state after adjustment (solid box B94), partition 0 only stores the associated module RM0, while partition 2 is updated to simultaneously store the associated module RM2 and the target submodule TSM. Therefore, in the later stages of operation, when the processor 110 frequently runs the associated module RM2 (ErrorHandle module) and calls the target submodule TSM, the target submodule TSM will be loaded into the partition loading area 132 along with partition 2, achieving optimal I / O performance for the current operational phase without requiring additional partition loading operations.

[0101] It is worth mentioning that, in another embodiment, changes in the operating state of the electronic device 100 not only cause changes in the first weighted parameter but may also cause simultaneous changes in the second weighted parameter. For example, when the electronic device 100 performs a firmware update, the program code of each associated module changes, and the number of times each associated module calls the target submodule TSM (CopyUnit) in a single execution flow may change accordingly. Assume that before the firmware update, associated module RM0 (GC module) calls the target submodule TSM 3 times in a single execution flow; after the firmware update, due to the optimization of the garbage collection algorithm, the number of times associated module RM0 calls the target submodule TSM in a single execution flow changes to 5 times. In this case, the distribution of the second weighted parameter changes, and even if the first weighted parameter remains unchanged, the comprehensive evaluation value corresponding to each associated module will change due to the change in the second weighted parameter. In response to the firmware update event, the processor 110 re-acquires the call statistics data of the target submodule TSM corresponding to each associated module, wherein the call association information is re-determined based on the updated program code, and the call frequency information is re-statistically calculated according to the new statistical period. The processor 110 recalculates the comprehensive evaluation value of the target submodule TSM corresponding to each associated module based on the updated call statistics, and determines whether the library configuration of the target submodule TSM needs to be adjusted accordingly. In other words, the dynamic adjustment method disclosed herein is applicable not only to situations where the call frequency of each associated module changes, but also to situations where changes in the program code of each associated module itself lead to changes in the call association information.

[0102] It is worth mentioning that, in one embodiment, to avoid performance impact from code migration during system busy periods, the processor 110 can schedule the aforementioned "dynamic adjustment" operation to be performed during the idle time or background garbage collection of the electronic device 100. Furthermore, the migration process involves copying the target submodule's code to the reserved space in the new library and updating the symbol address table generated by the linker to ensure that subsequent instruction jumps correctly point to the new physical address.

[0103] Reference Figure 10 This document describes the triggering mechanism for dynamically adjusting the database configuration of the target submodule TSM. In one embodiment, to balance system overhead and the timeliness of performance optimization, dynamic adjustment can be initiated by two triggering methods: the preset period triggering shown in step S1010 and the running state change triggering shown in step S1020.

[0104] In step S1010, the processor 110 periodically triggers a dynamic adjustment process at a preset cycle. That is, every preset time interval, the processor 110 automatically re-executes the steps of obtaining call statistics, calculating the comprehensive evaluation value, and determining the target sub-module. The preset cycle can be flexibly set according to the usage scenario of the electronic device 100. For example, in the application scenario of an embedded storage controller, the preset cycle can be set to a week, a day, or other time units suitable for the usage frequency of the electronic device 100. By triggering the preset cycle, the processor 110 can periodically "check up" and update the call statistics of each related module, preventing configuration drift caused by long-term operation, and ensuring that the sub-module TSM's sub-module configuration remains in an optimal state throughout the entire operating lifecycle of the electronic device 100.

[0105] In step S1020, the processor 110 triggers a dynamic adjustment process in response to a change in the operating state of the electronic device 100. Changes in operating state include, but are not limited to, changes in the lifecycle stage of the electronic device 100 (e.g., moving from the early stage of operation to the later stage) or changes in operating mode (e.g., switching from a read-intensive mode to a write-intensive mode). Taking an embedded storage controller as an example, when the wear level (P / E cycle) of the storage medium reaches a certain threshold, the electronic device 100 is determined to have entered the later stage of operation. At this time, the call frequency of the wear leveling module and the error handling module tends to increase, while the call frequency of the garbage collection module may relatively decrease. Once the processor 110 detects an event indicating a change in the operating stage, it immediately triggers a process to reacquire call statistics to cope with the new load characteristics.

[0106] Regardless of whether it is triggered by step S1010 or step S1020, the processor 110 re-executes the aforementioned embodiment in step S1030 (e.g., Figure 2 or Figure 5 The steps of acquisition, calculation and determination in )

[0107] Specifically, the processor 110 re-acquires the latest call statistics of the target submodule TSM corresponding to each associated module, recalculates the comprehensive evaluation value based on the updated data, and determines the new target associated module accordingly. Subsequently, in step S1040, the processor 110 dynamically adjusts the database partitioning configured for the target submodule TSM based on the calculation results of step S1030. If the recalculated target associated module is consistent with the current configuration, the status quo is maintained; if a change occurs, the processor 110 performs a code migration operation, transferring the target submodule TSM from the current database partitioning to the new target database partitioning (e.g., ...). Figure 9 (The process shown).

[0108] like Figure 10As shown in the trigger timeline diagram below, during the operation of electronic device 100, preset periodic triggering (represented by solid-lined periodic trigger points) and operational state change triggering (represented by dashed-lined event trigger points) can operate in parallel. At time points T1, T2, T3, T4, and T5, processor 110 performs regular dynamic adjustments according to the preset period. Between time points T3 and T4, if an operational stage change event occurs in electronic device 100 (e.g., wear level exceeds a threshold), processor 110 immediately responds to the change event by triggering an additional dynamic adjustment process at the current moment, without waiting for the next preset periodic trigger point T4. By combining the two triggering methods, processor 110 can ensure long-term configuration stability through periodic triggering and achieve immediate response to sudden state changes through event triggering, enabling the database configuration of the target submodule TSM to adapt to the current operational status of electronic device 100.

[0109] It should be noted that, in one embodiment, to avoid overly frequent adjustments, the processor 110 may also set a "cool-down period". For example, if an adjustment has just been completed during the event triggering between time points T3 and T4, and time point T4 is very close to the event triggering point (e.g., less than 1 hour), the processor 110 may choose to skip the periodic triggering at time T4 to save system computing resources.

[0110] In another embodiment, the processor 110 executes... Figure 10 During the dynamic adjustment process shown, not only are the call statistics of the identified target sub-modules re-acquired and the comprehensive evaluation value recalculated, but the target sub-module determination process in step S210 is also re-executed. That is, the sub-modules stored in multiple sub-libraries in memory 120 are re-traversed to identify all sub-modules that currently have call relationships with multiple associated modules. During the operation of electronic device 100, the call relationships between modules may change due to firmware updates, function expansions, or program code changes. For example, a newly added functional module may introduce a new sub-module that is jointly called by multiple associated modules, or a certain sub-module may no longer be jointly called by multiple associated modules. By periodically rescanning the call relationships of all modules, processor 110 can dynamically update the set of target sub-modules and execute steps S220 to S240 for each target sub-module in the set, so that all eligible shared sub-modules in electronic device 100 can be optimized by sub-library configuration, rather than being limited to the initially determined single target sub-module.

[0111] Reference Figure 11It describes the interaction process between the processor 110, the running memory 130 and the memory 120 in the process of dynamically adjusting the code library during execution in a time-series interactive manner.

[0112] In one embodiment, during the startup phase of the electronic device 100, the memory 120 first loads the program code from the common area into the runtime memory 130 (step S1111), so that the main program (e.g., firmware transition layer (FTL)) resides in the common area 131 of the runtime memory 130. Subsequently, the memory 120 loads the program code of a portion of the libraries into the library loading area 132 of the runtime memory 130 (step S1112), so that the processor 110 can execute the modules currently required. Since the library loading area 132 can only load and run a portion of the libraries from multiple libraries at a time, this phase only loads the libraries required for initial operation.

[0113] After completing the startup phase, processor 110 begins executing the dynamic adjustment method for code library partitioning. Processor 110 traverses the sub-modules stored in multiple partitions of memory 120 (step S1121), and memory 120 returns the calling relationships between each sub-module and multiple associated modules (step S1122). Based on the calling relationships, processor 110 determines the target sub-module that has calling relationships with multiple associated modules within the multiple modules (step S1131). Specifically, processor 110 identifies the sub-module that is jointly called by multiple associated modules from the calling relationships and determines it as the target sub-module.

[0114] Next, the processor 110 obtains the call statistics of the target submodule corresponding to each associated module (step S1132). The call statistics include the call frequency information of each associated module and the call association information between each associated module and the target submodule. Based on the call statistics, the processor 110 calculates the comprehensive evaluation value of the target submodule corresponding to each associated module (step S1133) and determines the target associated module corresponding to the comprehensive evaluation value (step S1134), that is, the associated module corresponding to the one with the largest comprehensive evaluation value among multiple associated modules. Steps S1132 to S1134 are all executed internally by the processor 110. Figure 5 The calculation process for steps S510 to S550 is shown.

[0115] After determining the target associated module, the processor 110 configures the target submodule in the target sub-library corresponding to the target associated module (step S1141). Subsequently, when the processor 110 needs to run the target associated module, the processor 110 requests the memory 120 to load the target sub-library (step S1142), and the memory 120 loads the program code of the target sub-library into the sub-library loading area 132 of the running memory 130 (step S1143). Since the target submodule has been configured in the target sub-library, the program code of the target submodule is loaded into the sub-library loading area 132 along with the target sub-library, without the need to perform additional sub-library loading operations. After the program code in the running memory 130 is ready, the processor 110 executes the target associated module and the target submodule from the sub-library loading area 132 (step S1144).

[0116] During the subsequent operation of the electronic device 100, the processor 110 continuously monitors the operating status of the electronic device 100. When the processor 110 detects a change in the operating status (step S1151), the processor 110 re-acquires the call statistics of the target sub-module corresponding to each associated module (step S1152), and recalculates the comprehensive evaluation value of the target sub-module corresponding to each associated module based on the updated call statistics (step S1153). If the recalculated target associated module is inconsistent with the currently configured target associated module, that is, the target associated module has changed, the processor 110 migrates the target sub-module from its current sub-database to the target sub-database corresponding to the new target associated module (step S1161), and the memory 120 loads the updated target sub-database into the sub-database loading area 132 of the running memory 130 (step S1162). Through the above dynamic adjustment process, the sub-database configuration of the target sub-module can be updated as the operating status of the electronic device 100 changes.

[0117] It is worth mentioning that, in one embodiment, the "load" operation in steps S1112, S1143, and S1162 can be completed by the Direct Memory Access (DMA) controller under the scheduling of the processor 110. The processor 110 only needs to provide the DMA controller with the source address (the address of the sub-library in memory 120) and the target address (the address of the sub-library loading area in running memory 130), and the DMA controller can efficiently complete the code migration without occupying the core computing resources of the processor 110. This disclosure directly reduces the frequency of the DMA controller being called by reducing the "number" of load operations, thereby saving bus bandwidth and power consumption.

[0118] It should be noted that in the above embodiments, the electronic device 100 is described using an embedded storage controller (e.g., an embedded multimedia card (eMMC) controller) as an example, and the multiple associated modules are exemplified by a garbage collection (GC) module, a wear leveling (WL) module, and an error handling (ErrorHandle) module, with the target submodule being an example of a data copy submodule (CopyUnit). However, this disclosure is not limited thereto. The electronic device 100 can be any electronic device employing a code library sharding mechanism, including but not limited to microcontrollers (MCUs), digital signal processors (DSPs), Internet of Things (IoT) terminal devices, or universal flash memory (UFS) controllers. The multiple associated modules and target submodules can be any functional modules and submodules in the electronic device 100 that have the above-described calling relationships, and this disclosure does not limit their specific functional types.

[0119] Furthermore, in the above embodiments, the number of associated modules is illustrated using three as an example. However, this disclosure is not limited to this. The number of associated modules can be any number, two or more, as long as there is a calling relationship between the target submodule and the associated modules, the method of this disclosure can be applied. Similarly, the number of sub-databases in the memory 120 is not limited to the specific numbers listed in the above embodiments.

[0120] It is worth mentioning that, in another embodiment, the electronic device 100 is a microcontroller (MCU) applied to IoT terminal devices. The microcontroller's RAM 130 has limited capacity, and its program code is managed using a code sharding mechanism. In this application scenario, multiple modules, including a sensor data acquisition module, a wireless communication module, and a data encryption module, are configured in different shards. The sensor data acquisition module is used to read data from external sensors, the wireless communication module is used to send data to a remote server via a wireless protocol, and the data encryption module is used to encrypt the transmitted data. Each of these three modules needs to call a buffer management submodule to allocate and release data buffers during its respective execution flow; therefore, the buffer management submodule is the target submodule called by all three related modules. The processor 110 obtains the call statistics of the buffer management submodules corresponding to the three related modules, calculates the comprehensive evaluation value of the buffer management submodule corresponding to each related module, and configures the buffer management submodule in the shard corresponding to the related module with the highest comprehensive evaluation value. For example, when the terminal device is in the high-frequency data reporting phase, the wireless communication module is called frequently and the buffer management submodule is called many times in a single execution process. The processor 110 can configure the buffer management submodule in the sub-database corresponding to the wireless communication module. When the terminal device enters the intensive acquisition phase, the call frequency of the sensor data acquisition module increases. The processor 110 can respond to the change in operating status, recalculate the comprehensive evaluation value, and migrate the buffer management submodule to the sub-database corresponding to the sensor data acquisition module. The above process is the same as the method steps used in the aforementioned embedded storage controller embodiment, the only difference being the different specific functional types of the multiple associated modules and target sub-modules, which will not be repeated here.

[0121] In another embodiment, the electronic device 100 may contain multiple target sub-modules simultaneously, meaning multiple sub-modules that are jointly invoked by at least two of the multiple associated modules. For example, in addition to the data copy sub-module (CopyUnit) in the aforementioned embodiment, the electronic device 100 may also contain a buffer management sub-module (BufferManager), which is also invoked by at least two of the associated modules RM0 (GC module), RM1 (WL module), and RM2 (ErrorHandle module) in their respective execution flows. In this case, when the processor 110 traverses the sub-modules stored in the multiple sub-databases of the memory 120 in step S210, it can identify multiple target sub-modules, namely the data copy sub-module (CopyUnit) and the buffer management sub-module (BufferManager).

[0122] Processor 110 executes steps S220 to S240 for each target submodule, obtaining call statistics for each target submodule corresponding to each associated module, calculating the corresponding comprehensive evaluation value, and determining the target associated module for each target submodule based on the comprehensive evaluation value. However, when the target associated modules of multiple target submodules point to the same associated module, configuration conflicts may occur. For example, the comprehensive evaluation value of the data copy submodule (CopyUnit) indicates that it should be configured in the partition 0 corresponding to the associated module RM0 (GC module), while the comprehensive evaluation value of the buffer management submodule (BufferManager) also indicates that it should be configured in partition 0. If the available capacity of partition 0 cannot accommodate the program code of two target submodules simultaneously, processor 110 needs to coordinate the configuration between multiple target submodules.

[0123] In one embodiment, the processor 110 employs a global optimization strategy to handle the aforementioned configuration conflict. Specifically, the processor 110 sorts multiple target sub-modules in descending order according to the maximum value of their respective comprehensive evaluation values, and prioritizes allocating the target sub-module with the highest comprehensive evaluation value to its corresponding target database. For subsequent target sub-modules, if their corresponding target database is insufficient, the processor 110 selects the database corresponding to the associated module with the second highest comprehensive evaluation value as an alternative target database. Continuing the above example, assuming the comprehensive evaluation value of the associated module RM0 corresponding to the data copy sub-module (CopyUnit) is 0.21, and the comprehensive evaluation value of the associated module RM0 corresponding to the buffer management sub-module (BufferManager) is 0.18, the processor 110 prioritizes configuring the data copy sub-module (CopyUnit) in database 0, and then configures the buffer management sub-module (BufferManager) in the database corresponding to its associated module with the second highest comprehensive evaluation value.

[0124] In another embodiment, the processor 110 can perform global optimization using an overall benefit evaluation approach. For all possible configuration combinations of multiple target sub-modules, the processor 110 calculates the total number of expected database loading operations for each combination and selects the configuration combination with the fewest expected database loading operations as the final solution. For example, in the case of two target sub-modules and three databases, the processor 110 calculates the sum of the number of database loading operations triggered by each associated module when calling the two target sub-modules under each configuration combination (e.g., CopyUnit configured in database 0 and BufferManager configured in database 1, CopyUnit configured in database 0 and BufferManager configured in database 2, etc.), and selects the combination with the fewest total operations. This method can achieve a better configuration result at the global level when the number of target sub-modules is small. However, as the number of target sub-modules increases, the number of configuration combinations grows exponentially. The processor 110 can choose the aforementioned priority ranking strategy or overall benefit evaluation strategy based on the computing resources of the electronic device 100.

[0125] In another embodiment, when calculating the first weighted parameter, the processor 110 not only uses the number of calls to each associated module in the current statistical period, but also incorporates the historical number of calls in the previous few statistical periods into the calculation, so that the first weighted parameter can reflect the changing trend of the call frequency of each associated module.

[0126] Specifically, the processor 110 maintains a set of historical call records, recording the number of calls made by each associated module within the most recent K statistical periods, where K is a preset historical window length. The processor 110 assigns different time decay coefficients to the call counts for each of the K statistical periods; the closer the call count is to the current statistical period, the larger the time decay coefficient, and the further away the call count is from the current statistical period, the smaller the time decay coefficient. For example, when K=3, the processor 110 sets the time decay coefficient for the current statistical period to 1, the time decay coefficient for the previous statistical period to 0.5, and the time decay coefficient for the two previous statistical periods to 0.25.

[0127] The processor 110 multiplies the number of calls to each associated module in each statistical period by the corresponding time decay coefficient and then sums them to obtain the decay-weighted call count for each associated module. Subsequently, the processor 110 determines the first weighting parameter for each associated module based on the proportion of the decay-weighted call count of each associated module to the total decay-weighted call count of multiple associated modules.

[0128] Let's take the associated module RM0 (GC module) as an example. Assume the number of calls to associated module RM0 in the last three statistical periods are: 70 times in the current period, 80 times in the previous period, and 90 times in the two periods before that. The corresponding time decay coefficients are 1, 0.5, and 0.25, respectively. Then, the decay-weighted call count for associated module RM0 is 70×1 + 80×0.5 + 90×0.25 = 70 + 40 + 22.5 = 132.5. Assume the decay-weighted call count for associated module RM1 (WL module) is 45, and the decay-weighted call count for associated module RM2 (ErrorHandle module) is 72.5. Then, the total decay-weighted call count is 132.5 + 45 + 72.5 = 250. Accordingly, the first weighted parameter of the associated module RM0 is 132.5 / 250=53%, the first weighted parameter of the associated module RM1 is 45 / 250=18%, and the first weighted parameter of the associated module RM2 is 72.5 / 250=29%.

[0129] Compared to Figure 6 The method shown calculates the first weighted parameter based solely on the current statistical period. The historical decay weighting method described above ensures that the first weighted parameter not only reflects the call distribution within the current statistical period but also incorporates call information from historical statistical periods. In the example above, the number of calls to the associated module RM0 shows a decreasing trend over the last three statistical periods (90→80→70). After decay weighting, its first weighted parameter is 53%, lower than the 70% calculated based solely on the current period. This result demonstrates that the historical decay weighting method can reflect the decreasing trend in call frequency, making configuration decisions more forward-looking to some extent. Furthermore, because it smooths occasional call fluctuations within a single statistical period over multiple periods, the historical decay weighting method can reduce unnecessary database migration operations triggered by occasional fluctuations.

[0130] In one embodiment, the historical window length K and the time decay coefficient corresponding to each statistical period can be preset by the developers according to the application scenario of the electronic device 100. In another embodiment, the processor 110 can adaptively adjust the value of the historical window length K according to the variation of the number of calls to each associated module between adjacent statistical periods: when the variation of the number of calls is large, the value of K is decreased to increase the response speed to recent data; when the variation of the number of calls is small, the value of K is increased to enhance the smoothing effect.

[0131] In another embodiment, when dynamically adjusting the database sharding configured by the target submodule TSM, the processor 110 further evaluates the cost of the migration operation itself after recalculating the comprehensive evaluation value and before performing the database sharding migration, and only performs the database sharding migration when the expected migration benefits exceed the migration costs.

[0132] Specifically, when processor 110 discovers a change in the target associated module after recalculating the comprehensive evaluation value in step S1153, processor 110 does not immediately perform database migration. Instead, it first calculates the migration benefit value and migration cost value. The migration benefit value represents the expected reduction in the number of database loading operations after migration. Based on the distribution of the recalculated comprehensive evaluation value, processor 110 estimates the number of database loading operations triggered by each associated module when calling the target submodule TSM in the next statistical period, after migrating the target submodule TSM from the current database to the new target database. The processor 110 then calculates the difference between this number and the expected number of database loading operations when maintaining the current configuration to obtain the migration benefit value.

[0133] The migration cost represents the processing resources consumed by performing the migration operation itself. The migration operation includes moving the program code of the target submodule TSM from its current location in the database to a new target database, updating the mapping relationship between the database and the submodule in memory 120, and reloading the updated target database to the database loading area 132 when necessary. All of these operations consume a certain amount of processing time and storage bandwidth. The processor 110 converts the processing resources consumed by the migration operation into an equivalent number of database loading operations, which is then used as the migration cost.

[0134] Processor 110 compares the migration benefit value with the migration cost value. When the migration benefit value is greater than the migration cost value, it indicates that the reduction in the number of database loading operations brought about by the migration operation is sufficient to offset the resource consumption of the migration operation itself. Processor 110 performs the database migration, migrating the target submodule TSM from the current database to the new database corresponding to the target associated module. When the migration benefit value is less than or equal to the migration cost value, it indicates that the resource consumption of the migration operation itself is close to or even exceeds the reduction in the number of database loading operations it can bring. Processor 110 maintains the current database configuration of the target submodule TSM unchanged and waits for the next trigger to re-evaluate.

[0135] Let's illustrate this with a numerical example. Suppose that after recalculating the comprehensive evaluation value, processor 110 finds that the current target associated module is associated module RM0 (GC module, database shard 0), and the new target associated module is associated module RM2 (ErrorHandle module, database shard 2). Processor 110 estimates that if the current configuration is maintained, the number of database shard loading operations triggered by calling the target submodule TSM in the next statistical period will be 120; if migration is performed, this number is expected to decrease to 45. Therefore, the migration benefit is 120 - 45 = 75 operations. Simultaneously, processor 110 estimates that the processing resources consumed by performing one migration operation are equivalent to 10 database shard loading operations, i.e., the migration cost is 10 operations. Since the migration benefit (75 operations) is greater than the migration cost (10 operations), processor 110 performs the database shard migration. Conversely, assuming another scenario where the migration benefit is only 8 operations and the migration cost is 10 operations, processor 110 maintains the current configuration.

[0136] In one embodiment, the processor 110 may introduce a migration threshold parameter to control the sensitivity of migration decisions. The migration threshold parameter is a preset positive value, and the processor 110 only performs database sharding migration when the difference between the migration benefit value and the migration cost value exceeds the migration threshold parameter. By adjusting the size of the migration threshold parameter, a trade-off can be struck between migration response speed and system stability: a smaller migration threshold parameter allows the processor 110 to respond quickly to changes in the overall evaluation value, but may lead to frequent migrations; a larger migration threshold parameter allows the processor 110 to perform migration only when the migration benefit is sufficiently clear, thereby reducing unnecessary migration operations.

[0137] In another embodiment, this disclosure also provides a computer-readable storage medium storing a computer program. When the computer program is executed by the processor 110, it implements the dynamic adjustment method for code partitioning in the above embodiments. The computer-readable storage medium includes, but is not limited to, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), flash memory, or other media capable of storing computer programs in a non-volatile manner. When the computer program is loaded into the running memory 130 of the processor 110 for execution, the processor 110 performs the steps of determining the target submodule, obtaining call statistics, calculating the comprehensive evaluation value, and configuring the target submodule in the target partitioning. The specific execution process is the same as the methods in the foregoing embodiments and will not be repeated here.

[0138] In summary, the dynamic adjustment method and electronic device for code sub-databases provided in this disclosure, by acquiring call statistics data of the target sub-module corresponding to each associated module and calculating a comprehensive evaluation value, enables the electronic device to quantitatively determine the configuration position of the target sub-module in multiple sub-databases, configuring the target sub-module in the sub-database corresponding to the associated module with a high degree of call correlation. Compared to the existing technology where developers statically set the sub-module position based on experience during the compilation stage, the method of this disclosure makes configuration decisions based on actual call statistics data, thus correlating the configuration results with the actual operating status of the electronic device.

[0139] Specifically, the call statistics disclosed herein include two dimensions: call frequency information and call association information, representing the activity level of each associated module and the dependence of each associated module on the target sub-module, respectively. By integrating the information from the two dimensions into a comprehensive evaluation value through the product of a first weighting parameter and a second weighting parameter, the method of this disclosure can avoid the bias that may arise from relying on only a single dimension for configuration decisions. Figures 6 to 8 In the illustrated embodiment, although the second weighted parameter (50%) of the associated module RM2 (ErrorHandle module) is the highest among the three associated modules, its first weighted parameter (30%) is lower than that of the associated module RM0 (GC module) (70%). Therefore, after comprehensive evaluation, the overall evaluation value of associated module RM0 (0.21) is still higher than that of associated module RM2 (0.15). This result indicates that, under the current operating conditions, configuring the target submodule in the database corresponding to associated module RM0 results in fewer database loading operations triggered by calling the target submodule compared to configuring it in the database corresponding to associated module RM2.

[0140] Furthermore, the method of this disclosure can respond to changes in the operating state of the electronic device, re-acquire call statistics, and dynamically adjust the database configuration of the target submodule. For example... Figure 9 In the illustrated embodiment, when the electronic device 100 transitions from the initial stage of operation to the later stage, the first weighted parameters of each associated module change, and the distribution of the recalculated comprehensive evaluation value also changes accordingly. The target associated module changes from associated module RM0 (GC module) to associated module RM2 (ErrorHandle module), and the target submodule TSM correspondingly migrates from library 0 to library 2. Through a dynamic adjustment mechanism, the library configuration of the target submodule is no longer limited to the fixed scheme determined during the compilation stage, but can continuously adapt to the current operating conditions in different operating stages of the electronic device.

[0141] Furthermore, when at least two related modules have the same comprehensive evaluation value, both of which are the maximum value, the method disclosed herein introduces database loading frequency data as an auxiliary criterion to select the database corresponding to the one with the higher loading frequency as the target database. Since the database with a higher loading frequency has a greater chance of being loaded into the database loading area during runtime, configuring the target submodule in that database increases the probability that the target submodule will be loaded along with that database, thus providing a technically reasonable decision-making basis for situations where the comprehensive evaluation values ​​are the same.

[0142] At the device level, the electronic device disclosed herein, through the collaboration of the processor and memory, achieves configuration optimization and dynamic adjustment of the target submodule under the hardware constraint that the library loading area of ​​the running memory can only support the loading and execution of a portion of the libraries. When the processor runs the target associated module, the target submodule is loaded into the library loading area along with the target library and can run immediately, sharing the same library loading operation with the target associated module, without needing to trigger additional library loading operations due to calling the target submodule.

[0143] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for dynamically adjusting code sub-libraries, applied to an electronic device, the electronic device having multiple sub-libraries, each sub-library storing program code corresponding to multiple modules, characterized in that... The method includes: Identify the target sub-module that has a calling relationship with multiple associated modules within the multiple modules; Obtain the call statistics for the target sub-module corresponding to each associated module; Based on the call statistics, calculate the comprehensive evaluation value of each associated module corresponding to the target sub-module; and Based on the comprehensive evaluation value, the target associated module within the plurality of associated modules is determined, and the target sub-module is configured in the target sub-database corresponding to the target associated module in the plurality of sub-databases.

2. The method according to claim 1, characterized in that, The multiple associated modules call the target sub-module in their respective execution flows, and the target sub-module can be configured in any of the multiple sub-databases.

3. The method according to claim 1, characterized in that, The method further includes: In response to changes in the operating state of the electronic device, the call statistics data corresponding to the target sub-module for each associated module are re-acquired in order to dynamically adjust the database configuration of the target sub-module.

4. The method according to claim 1, characterized in that, When at least two of the plurality of associated modules have the same comprehensive evaluation value and both are the maximum value, the step of configuring the target sub-module in the target sub-database corresponding to the target associated module in the plurality of sub-databases includes: Obtain the database loading frequency data of the respective databases of the at least two associated modules; and The database corresponding to the database with the highest loading frequency is selected as the target database, and the target submodule is configured in the target database.

5. The method according to claim 1, characterized in that, The call statistics include call frequency information for each associated module and call association information between each associated module and the target sub-module.

6. The method according to claim 5, characterized in that, The method further includes: The comprehensive evaluation value is calculated based on a first weighting parameter and a second weighting parameter, wherein the first weighting parameter is determined based on the call frequency information and the second weighting parameter is determined based on the call association information.

7. The method according to claim 6, characterized in that, The first weighting parameter is the proportion of the number of times each associated module is called within a statistical period to the total number of times the multiple associated modules are called within the statistical period. The second weighting parameter is the ratio of the number of times each associated module calls the target sub-module in a single execution flow to the total number of times the multiple associated modules call the target sub-module in their respective single execution flows.

8. The method according to claim 6, characterized in that, The comprehensive evaluation value is the product of the first weighted parameter and the second weighted parameter.

9. The method according to claim 1, characterized in that, The target association module is the association module corresponding to the one with the largest comprehensive evaluation value among the multiple association modules.

10. An electronic device, characterized in that, include: The memory has multiple sub-libraries, each of which is used to store program code corresponding to multiple modules; as well as A processor is connected to the memory. The processor has running memory, which includes a common area and a sub-database loading area. The sub-database loading area can only load and run a portion of the multiple sub-databases. The processor is configured to: Identify the target sub-module that has a calling relationship with multiple associated modules within the multiple modules; Obtain the call statistics for the target sub-module corresponding to each associated module; Based on the call statistics, calculate the comprehensive evaluation value of each associated module corresponding to the target sub-module; as well as Based on the comprehensive evaluation value, the target associated module within the plurality of associated modules is determined, and the target sub-module is configured in the target sub-database corresponding to the target associated module in the plurality of sub-databases, so that when the processor runs the target associated module, the target sub-module is loaded into the sub-database loading area along with the target sub-database.

Images