Embedded system-oriented perfect hash quick search method

Abstract

The invention provides a perfect hash quick searching method for an embedded system, and relates to the technical field of hash searching, the method comprises a construction stage and a searching stage, the construction stage comprises the following steps: mapping a static key set into a plurality of buckets through a hash function, and arranging all the buckets in a descending order according to the size; distributing a unique guide value for each bucket, generating a conflict-free hash position and marking an occupation state; establishing an original index of a reverse lookup table record key; the searching stage comprises the following steps: calculating an initial hash value of an input key and determining a bucket to which the initial hash value is mapped; acquiring a guidance value of the determined bucket and calculating the position of the bucket; and returning a real index value corresponding to the position through the reverse lookup table. The method provided by the invention not only can eliminate Hash conflicts during operation and guarantee real-time performance, but also can well adapt to embedded resource limitation, and in addition, can effectively improve system reliability. According to the method, the most sensitive real-time performance and resource bottleneck problems of an embedded scene can be fundamentally avoided.

Description

Technical Field

[0001] The present invention relates to the technical field of hash search, and in particular to a perfect hash fast search method for embedded systems. Background Art

[0002] Hashing technology is a key method for improving table lookup efficiency in embedded systems and is widely used in scenarios such as protocol mapping and command distribution. However, embedded platforms are characterized by resource constraints, high real-time requirements, and a lack of support for dynamic memory allocation. Traditional conflict resolution schemes (such as open addressing and chained addressing) face challenges such as increased lookup latency, low cache hit rates, and excessive memory usage when load factors increase, making them difficult to meet stable real-time requirements.

[0003] While various perfect hashing algorithms exist, many still face limitations in practical deployment, such as complex construction, strong reliance on auxiliary structures, and difficulty running efficiently on resource-constrained platforms. In recent years, the PTHash algorithm, as an efficient construction solution, has shown promising application prospects on embedded platforms due to its simple search logic and low construction overhead. However, its variable-length compression table requires multiple decoding cycles, resulting in high query latency. Furthermore, hash function calculations (e.g., XXHash) require high MCU resources, and compression strategies are not optimized for embedded storage models, leaving room for improvement in space utilization.

[0004] Therefore, how to optimize the PTHash algorithm in the application scenario of embedded systems has become an urgent problem to be solved. Summary of the Invention

[0005] In order to solve the problems in the related art, the present invention provides a perfect hash fast search method for embedded systems.

[0006] In order to achieve the above object, the technical solution adopted by the present invention is: A perfect hash fast search method for embedded systems includes a construction phase and a search phase, wherein the construction phase includes: Step S1-1: Map the static key set to multiple buckets through a hash function; Step S1-2: Arrange all buckets in descending order of size; Step S1-3: assign a unique guide value to each bucket, generate a conflict-free hash position and mark the occupied state; Step S1-4: Create the original index of the reverse lookup record key; The search phase includes: Step S2-1: Calculate the initial hash value of the input key and determine the bucket it is mapped to; Step S2-2: Obtain the guidance value of the bucket determined in step S2-1 and calculate its position; Step S2-3: Return the real index value corresponding to the position through reverse table lookup.

[0007] Optionally, in step S1-1, the number of buckets Determined by the following formula: Where c is an adjustable constant and n is the number of bonds.

[0008] Optionally, the adjustable constant c is set to 3.0, and the loading factor α in the construction phase is set to 1.0.

[0009] Optionally, in step S1-2, a dual-pivot quick sort algorithm is used to sort the buckets in descending order.

[0010] Optionally, step S1-3 includes: Step S1-3-1: Use the auxiliary array taken[0,…,n-1] to record the occupied status of the positions in the key set key[n]={0,…,n-1}; select the seed s for the pseudo-random hash function h(x,s) to ensure that the keys in the same bucket have different hash values; Step S1-3-2: For each bucket Search for an integer reference value , so that all keys x in the bucket satisfy the position formula: Where, Indicates that the key value x is in the reference value The position value calculated under the conditions of Indicates guide value The hash value calculated under the seed s, Indicates guide value The hash value calculated under the seed s represents a modulo operation, where n is the number of keys. Indicates whether the calculated position value is occupied. A value of 1 indicates occupied, and a value of 0 indicates unoccupied. If the location is not occupied, the search is considered successful and the location is marked as occupied. Store in the Pilot array, otherwise try the next one value until all keys in the bucket are successfully placed.

[0011] Optionally, the step S1-3-2 further includes: simultaneously establishing a reverse lookup table for each successfully placed key value and recording its position index.

[0012] Optionally, the pilot array and reverse lookup table are stored using a fixed-length bit compression method.

[0013] Optionally, in step S1 - 1 , a lightweight hash function h(x, s) is used to map the static key to the bucket, where the lightweight hash function h(x, s) only includes integer XOR and shift operations.

[0014] Optionally, the search phase specifically includes: Step S2-1: Use the hash function to calculate the initial hash value corresponding to the input key x and determine the bucket it is mapped to; Step S2-2: Use fixed-length bit compression to query the index value corresponding to the bucket determined in step S2-1 , and has been stored in the Pilot array and saved by bit compression during the construction process; Step S2-3: Calculate the final position in the lookup table based on the initial hash value calculated in step S2-1, use fixed-length bit compression to query the reverse lookup table data at that position, and return the corresponding real index value.

[0015] Beneficial effects: 1. Through the above technical solution, the method of the present invention can first eliminate hash conflicts during runtime and ensure real-time performance. Specifically, the method of the present invention completely resolves the hash conflict problem during the construction phase through a search step in the construction phase (assigning a unique reference value to each bucket and generating a conflict-free location). The search phase does not require dynamic conflict processing (such as linear probing for open addressing or linked list traversal for chained addresses), so each query only requires fixed steps, achieving a strictly constant time complexity (O(1)), meeting the stringent requirements of embedded systems for stable and low latency.

[0016] Second, the method of the present invention is well adapted to embedded resource constraints. Specifically, the method of the present invention avoids dynamic memory allocation at runtime through a static build + reverse lookup table design. Computationally intensive operations such as mapping, sorting, and searching are completed in an offline preprocessing phase, eliminating the need for embedded device computing resources. The search phase requires only two hash calculations and two table accesses (bucket location and position calculation), eliminating complex logical branching and resulting in predictable memory usage. The reverse lookup table solidifies and stores the original index, eliminating the need to maintain key-value mappings at runtime and reducing RAM consumption.

[0017] Third, the method of the present invention can effectively improve system reliability. Specifically, the sorting step of the present invention processes buckets in descending order by bucket size, prioritizing buckets with high collision probability, reducing the risk of build failure, and ensuring hash table availability. Furthermore, a non-collision position marking mechanism (using an auxiliary array to record occupancy status) ensures unique key mapping, eliminating the risk of data overwriting or loss during runtime.

[0018] Overall, the core improvement of the above implementation lies in shifting conflict resolution from runtime to build time. Traditional hash tables dynamically handle conflicts at runtime, resulting in uncontrollable latency. The solution of the present invention statically allocates conflict-free locations at build time, requiring only deterministic operations at runtime. This improvement fundamentally avoids the real-time and resource bottlenecks that are most sensitive in embedded scenarios.

[0019] 2. Other beneficial effects or advantages of the present invention will be described in detail in the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0021] in: Figure 1 This is a flowchart of a perfect hash fast search method for an embedded system provided by an exemplary embodiment of the present invention; Figure 2 This is a flowchart of traditional hashing and perfect hashing lookup. Figure 3 1 is a flow chart of the improved PTHash algorithm construction phase provided by an exemplary embodiment of the present invention; Figure 4 is a flow chart of a dual-pivot quick sort algorithm provided by an exemplary embodiment of the present invention; Figure 5 1 is a flow chart of the search phase of the improved PTHash algorithm provided by an exemplary embodiment of the present invention; Figure 6 1 is a schematic diagram comparing the space occupancy of a traditional method and a perfect hash method provided by an exemplary embodiment of the present invention; Figure 7 An exemplary embodiment of the present invention provides a schematic diagram of the time consumption for hash table initialization under different load factors; Figures 8 to 11 This is a diagram showing the time taken to initialize a hash table under different load factors using a traditional hash algorithm. Figures 12 to 15 FIG. 1 is a schematic diagram comparing the search time of perfect hash and traditional hash provided by an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments.

[0023] Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention as claimed, but rather merely represents selected embodiments of the present invention. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without creative effort are intended to fall within the scope of protection of the present invention.

[0024] In addition, the terms "including" and "having" and any variations thereof mentioned in the description of the present invention are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include other steps or units that are not listed, or may optionally include other steps or units that are inherent to these processes, methods, products or devices. It should also be noted that in the embodiments of the present invention, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of the present invention should not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way.

[0025] In order to facilitate relevant technical personnel to have a clearer and more accurate understanding of the technical solution of the present invention, the existing related technologies and the technical problems existing therein are first described in more detail below.

[0026] First, the existing hash table lookup method is described.

[0027] According to different conflict handling and search performance optimization strategies, existing hash table lookup methods mainly include: open addressing method, chain address method, multi-hash method and perfect hash method.

[0028] Among them, open addressing methods offer simple implementation, high search and build efficiency, and are suitable for resource-constrained environments. Linear probing, in particular, is often adopted in embedded systems due to its excellent cache locality. However, when the load factor increases, frequent conflicts lead to longer probing paths and significantly increased search latency, making it difficult to achieve stable real-time performance in extreme cases.

[0029] The chain address method manages conflicting data through linked lists or arrays, which has an intuitive structure and is simple to implement. However, due to the frequent random memory access, the cache hit rate is reduced, and the pointer structure takes up a lot of space, it is difficult to adapt to the memory model of embedded platforms.

[0030] To improve conflict resolution efficiency, multi-hash structures such as cuckoo hashing and cascade hashing propose using multiple independent hash functions to insert elements into multiple candidate locations or redistribute them based on the fairness of the detection path. While these methods can improve average search performance, they suffer from several drawbacks: The construction phase often requires dynamic migration or even rollback and reconstruction; multiple hash function calculations impose a heavy CPU burden, particularly on C-based embedded platforms, where hash functions cannot be optimized with SIMD or vector instructions, limiting efficiency; and the need to store metadata or auxiliary tables increases memory consumption. Therefore, multi-hash is limited in resource-constrained, real-time-critical embedded environments.

[0031] In existing applications, open-addressable hash tables and multi-hash structures are widely used, but both require hash collision resolution during lookups, making them inadequate for embedded platforms. For example, multi-hash structures offer certain advantages in search efficiency, but their complex construction process, high resource consumption, and strong dependence on the quality of the hash function limit their universal applicability on embedded platforms. Consequently, in recent years, increasing research has focused on constructing perfect hash functions that are efficient, have stable search performance, and utilize minimal space.

[0032] For perfect hash functions (see Figure 2 ) is a collision-free hashing scheme that constructs a hash structure with collision-free lookups and constant query time for a given static key set. A perfect hash function offers the following advantages: highly deterministic lookup time, with no collisions resulting in constant, stable search performance; a compact and compressible structure, making it particularly suitable for embedded storage of static, read-only tables; and a simple query process, typically requiring only a simple hash calculation and table lookup.

[0033] Perfect hash functions provide a collision-free lookup structure for static sets, with constant lookup time, making them ideal for read-only lookup tables in embedded systems. Numerous papers on perfect hash functions exist in the existing literature. The following briefly analyzes the characteristics of different perfect hash algorithms for embedded platforms.

[0034] Please see Table 1 below Table 1 Analysis of different perfect hash algorithms on embedded platforms Although there are currently a variety of perfect hash algorithms, many methods still face many limitations in actual deployment, such as complex construction process, strong dependence on auxiliary structures, and difficulty in running efficiently on resource-constrained platforms.

[0035] In recent years, the PTHash algorithm, as an efficient construction solution, has shown promising application prospects on embedded platforms due to its simple search logic and low construction overhead. This algorithm, derived from an optimized design of the FCH algorithm, retains the latter's advantages in search efficiency while significantly simplifying the construction process and reducing reliance on external auxiliary structures. Compared with existing perfect hash algorithms, PTHash achieves a good trade-off between search performance and implementation complexity on embedded platforms, making it particularly suitable for space-sensitive systems with limited computing resources. However, its variable-length compression table requires multiple decodings, resulting in high query latency. Furthermore, hash function calculations (e.g., XXHash) require high MCU resources, and the compression strategy is not optimized for embedded storage models, leaving room for improvement in space utilization.

[0036] Therefore, how to optimize the PTHash algorithm in the application scenario of embedded systems has become an urgent problem to be solved.

[0037] In view of this, the present invention provides a new improved PTHash algorithm to meet the needs of hash search algorithm optimization in the application scenario of embedded systems.

[0038] The technical solution of the present invention is described in detail below with reference to the accompanying drawings.

[0039] like Figures 1 to 15 As shown, this embodiment provides a perfect hash fast search method for embedded systems, including a construction phase and a search phase, wherein the construction phase includes: Step S1-1: Map the static key set to multiple buckets through a hash function; Step S1-2: Arrange all buckets in descending order of size; Step S1-3: assign a unique guide value to each bucket, generate a conflict-free hash position and mark the occupied state; Step S1-4: Create the original index of the reverse lookup record key.

[0040] The search phase includes: Step S2-1: Calculate the initial hash value of the input key and determine the bucket it is mapped to; Step S2-2: Obtain the guidance value of the bucket determined in step S2-1 and calculate its position; Step S2-3: Return the real index value corresponding to the position through reverse table lookup.

[0041] Through the above technical solution, the method of the present invention can first eliminate runtime conflicts and ensure real-time performance. Specifically, the method of the present invention completely resolves the hash collision problem during the construction phase through a search step in the construction phase (assigning a unique reference value to each bucket and generating a conflict-free location). The search phase eliminates the need for dynamic conflict handling (such as linear probing for open addressing or linked list traversal for chained addresses), resulting in each query requiring only fixed steps and achieving strictly constant time complexity (O(1)), meeting the stringent requirements of embedded systems for stable and low latency.

[0042] Second, the method of the present invention is well adapted to embedded resource constraints. Specifically, the method of the present invention avoids dynamic memory allocation at runtime through a static build + reverse lookup table design. Computationally intensive operations such as mapping, sorting, and searching are completed in an offline preprocessing phase, eliminating the need for embedded device computing resources. The search phase requires only two hash calculations and two table accesses (bucket location and position calculation), eliminating complex logical branching and resulting in predictable memory usage. The reverse lookup table solidifies and stores the original index, eliminating the need to maintain key-value mappings at runtime and reducing RAM consumption.

[0043] Third, the method of the present invention can effectively improve system reliability. Specifically, the sorting step of the present invention processes buckets in descending order by bucket size, prioritizing buckets with high collision probability, reducing the risk of build failure, and ensuring hash table availability. Furthermore, a conflict-free position marking mechanism (using an auxiliary array to record occupancy status) ensures unique key mapping, eliminating the risk of data overwriting or loss during runtime.

[0044] Overall, the core improvement of the above implementation lies in shifting conflict resolution from runtime to build time. Traditional hash tables dynamically handle conflicts at runtime, leading to uncontrollable latency and memory fragmentation. The present invention, on the other hand, statically allocates conflict-free locations at build time, requiring only deterministic operations at runtime. This improvement fundamentally mitigates the real-time and resource bottlenecks that are so critical in embedded scenarios.

[0045] The following describes the technical solution of the present invention in detail by taking an exemplary embodiment of the present invention as an example with reference to the accompanying drawings.

[0046] See also Figure 3 , Figure 3 It is a flow chart of the construction phase of the improved PTHash algorithm of the present invention.

[0047] The construction phase of the improved PTHash algorithm of the present invention can include three steps, namely mapping, sorting, and searching. The specific implementation process is as follows: (1) In the mapping phase, instead of dividing the set into two subsets, all keys are directly mapped into one set. For a given constant c, map n keys to Buckets, recorded as ,The smaller the constant c is, the fewer the total number of buckets is, and the more keys each bucket has on average.

[0048] (2) After the mapping is completed, the dual-pivot quick sort algorithm is used to sort all buckets in descending order of size to prioritize buckets with high conflict probability, thereby speeding up the overall construction process. The process of the dual-pivot quick sort algorithm is as follows: Figure 4 shown.

[0049] (3) Use the auxiliary array taken[0,…,n-1] to record whether the position in the key set key[n]={0,…,n-1} is occupied. Then select the seed s for the pseudo-random hash function h(x,s) to ensure that the keys in the same bucket get different hash values. For each bucket , try searching for an integer , so that the positions of all keys in the bucket satisfy: If the location is not occupied, the search is considered successful and the location is marked as occupied ( ), then Store in the Pilot array. Otherwise, try the next value until all keys in the bucket are successfully placed. Integer A reference to bucket B, which determines the location of each key in that bucket.

[0050] Because perfect hashing results are not order-preserving, to ensure correct reverse lookup of key values ​​on embedded platforms, a reverse lookup table is created for each successfully placed key value, recording its original index. During the traversal process, once the number of keys in a bucket reaches 0, the construction process is considered complete.

[0051] During the construction process, a maximum number of attempts is set, random seeds are generated multiple times, and finally a seed is selected to minimize the maximum value in the Pilot array to save storage space after bit compression.

[0052] In this implementation, it's important to note that, first, traditional hash functions like XXHash and Siphash require high MCU resources and have complex computations, making them unsuitable for embedded MCUs. This invention employs a custom lightweight hash function, which uses only integer XOR and shift operations. This function offers high performance and can run quickly on low-power cores like the ARM Cortex-M, balancing speed and hashing performance. (It should be noted that subsequent experiments all utilize this lightweight hash function.) Second, taking into account the system load and compression performance, the present invention uses the Bit Packing (fixed-length bit compression) method to process the Pilot array and reverse lookup table. This method encodes the elements in the array with the minimum fixed-length bit width, and the compression results can be directly packaged as a standard uint32 array for storage, which is convenient for loading and accessing on the embedded platform. During decoding, fixed-length bit compression only requires simple shift and mask operations to restore the original value, and the query process can be completed in a constant time, completely avoiding the burden of dynamic memory management and complex function calls, and significantly improving operating efficiency. In addition, this method does not require any third-party library support, has clear logic, and low implementation cost, and is particularly suitable for resource-constrained systems in bare metal environments. Experiments show that while maintaining efficient search performance, the compression rate of fixed-length bit compression is close to the theoretical limit of information entropy, which can effectively reduce MCU resource usage and provide a practical solution for data-intensive applications on embedded platforms.

[0053] After the improved PTHash is built, the search process can be completed in constant time and the operation complexity is strictly controlled to meet the stringent requirements of embedded systems for latency and resources. The search phase can be composed of the following steps: (1) Use the hash function to calculate the initial hash value h(x,s) corresponding to the input key x and determine the bucket it is mapped to; (2) Use Bit Packing to query the parameters corresponding to the bucket ,This parameter serves as the guidance information for each bucket and is stored in the Pilot table and saved through bit compression during the construction process; (3) Using hash function calculation , there is no need to calculate h(x,s) again. Just use the hash value calculated in step (1) and calculate the final position in the lookup table according to the formula: (4) Use Bit Packing to query the reverse lookup table data at that location and return the corresponding real index value.

[0054] The search process only involves hash calculations, XOR operations, modulo operations, and array access, completely avoiding complex logic such as chain conflicts or rehashing. It can maximize the use of static information in the construction phase and achieve minimal computational burden at runtime. In actual deployment, the search performance is stable and the latency is extremely low, fully meeting the requirements of high-real-time, low-power embedded application scenarios. The flowchart of the entire search process can be found in Figure 5 shown.

[0055] To fully evaluate the performance of the proposed improved PTHash algorithm in an embedded environment, experiments were conducted on a high-performance PC and a resource-constrained MCU platform. The specific settings are as follows: (1) Construction phase: The construction process of the perfect hash function is completed on a PC. The platform used is a workstation equipped with an Intel i9-13900HX processor (@2.20GHz), equipped with 32GB DDR5 memory, and running the Windows 11 (64-bit) operating system. The processor is a 13th-generation Raptor Lake architecture with 24 cores (8 performance cores + 16 energy efficiency cores) and a maximum turbo frequency of 5.4GHz. Each performance core is equipped with an independent two-level cache: the L1 cache is 64KiB (32KiB instructions + 32KiB data), the L2 cache is 2MiB, and a 36MiB L3 cache is shared. To ensure reproducibility, the CPU frequency is fixed at the base frequency during the performance evaluation process, single-threaded execution is enabled, and dynamic scheduling mechanisms such as hyperthreading are turned off. The test data is completely resident in memory to eliminate interference.

[0056] (2) Search Phase: To verify the search efficiency and resource-friendliness of the proposed algorithm in embedded systems, we selected NXP's automotive-grade microcontroller, the S32K344, as the target platform. This chip is based on an Arm Cortex-M7 core with a 160MHz clock speed, 512KB of RAM, and 4MB of Flash memory, meeting the resource constraints and operating conditions of typical real-time embedded applications such as in-vehicle control. The experimental program runs in a bare-metal environment without operating system intervention, and all data structures are statically allocated.

[0057] The space and time comparison of the improved PTHash algorithm can be found in Table 2 below. Table 2 Comparison of space and time of improved PTHash algorithm The space occupied by the method of the present invention is analyzed below.

[0058] In traditional hash table design, collision handling is often done through open addressing (such as linear probing) or chain addressing. Its space usage mainly depends on the following two factors: the size of the original data set and the load factor of the hash table. Generally speaking, the smaller the load factor, the sparser the hash table and the lower the collision probability, but the overall space utilization will also decrease, resulting in greater memory overhead.

[0059] In contrast, perfect hash functions do not require dynamic conflict resolution mechanisms; their construction is completed offline. Lookups rely on only two fixed structures: a pilot table and a reverse lookup table, significantly reducing storage requirements and making them particularly suitable for resource-constrained embedded platforms.

[0060] In order to verify the space efficiency of the improved PTHash algorithm proposed in this paper in an embedded environment, a set of experiments were designed. The data set is used as the input data set, which represents the high-intensity data mapping scenario in the embedded platform. By adjusting the constant c and the loading factor in the build parameters , comparative analysis of the spatial performance under different configurations.

[0061] See also Figure 6 and Figure 7 ,in, Figure 6 Shows the difference between traditional hash table and perfect hash table at different load factors The space occupancy is as follows: Figure 7 The changing trend of the perfect hash construction time with c is given.

[0062] Through in-depth comparative analysis, it can be observed that whether using the traditional method or the perfect hash structure, the loading factor The smaller the load factor, the greater the space overhead. Therefore, in embedded systems, a higher load factor is more conducive to saving resources.

[0063] During the experiment, when the c value is small (c < 3.0), the number of buckets after the first hash mapping is small. Although space is saved, the probability of conflict increases significantly, and the probability of construction failure increases significantly. When the c value increases, the number of buckets after the first mapping step increases, the probability of conflict decreases, the construction success rate increases, the space required for the contrast table is not affected, but the space overhead of the pilot table increases accordingly. When c is large and When it is close to 1, in order to accommodate more empty slots and prevent conflicts, the maximum value of the Pilot will increase, and the compressed data will also increase. Therefore, the total space requirement of the hash table will also increase.

[0064] Taking into account the construction success rate, space overhead and time sensitivity of the embedded platform, this paper selects c=3.0. This configuration serves as the default for subsequent experiments. Under this configuration, the construction of the improved PTHash takes approximately 600ms, demonstrating good time controllability and is acceptable for preprocessing static data sets. At this point, the storage space required for the pilot table and reverse lookup table is minimized, resulting in optimal overall space utilization. Compared to traditional hash tables, the solution of the present invention reduces space overhead by an average of more than 50%, offering significant advantages in resource-constrained, space-sensitive embedded systems. (It should be noted that this parameter combination will continue to be used in subsequent search speed analyses to further evaluate the performance of this configuration in actual deployments.) The search time of the method of the present invention is analyzed below.

[0065] In order to more comprehensively evaluate the search performance of the improved PTHash algorithm proposed in this paper in embedded systems, the present invention designed and executed a series of benchmark experiments. The experimental data still used randomly generated key-value pairs, and the key-value pair size and compiler optimization level were adjusted for comparison. On this basis, the different construction parameter constants c and load factors were systematically analyzed. The impact on the overall lookup time is compared with the traditional hash table solution (see Table 3 below).

[0066] Table 3 Constant c and loading factor for different construction parameters Impact on overall search time table Traditional hash searches often rely on open addressing strategies such as linear probing to handle hash collisions. During the search phase, if a collision occurs, the search process will sequentially probe along the hash slots until the target key is found or an empty slot is encountered. This type of strategy usually maintains good performance at low and medium load factors, but as the load factor increases, the performance will decrease. As the number of queries increases, the frequency of conflicts increases and the length of the probe chain becomes longer, which significantly increases the search time. In addition, since ordinary hash tables need to be initialized before running, including allocating memory space, filling values, and preprocessing mapping structures, the time consumed in the startup phase cannot be ignored. We experimentally tested the initialization time under different load factors, such as Figures 8 to 11 shown.

[0067] from Figures 8 to 11 It can be observed that when When it is small, the hash table has more empty slots and the initialization process is relatively simple; When it is close to 1.0, although the space utilization rate is improved, the collision probability increases sharply, and the processing of the collision chain during the initialization process becomes complicated, resulting in a nearly monotonically increasing trend in the time consumption. In high-load areas, the increase in initialization time is more significant.

[0068] Unlike the aforementioned traditional methods, the improved PTHash is a static perfect hash algorithm that performs all conflict resolution and address allocation operations during the construction phase. During the search phase, each query requires only constant-time hash function computation and two table accesses, resulting in a strictly O(1) search complexity and stable performance, independent of whether the key exists in the hash set. This feature is particularly critical for real-time search tasks in embedded systems, effectively avoiding worst-case degradation.

[0069] See also Figures 12 to 15 , the experimental results show that the loading factor In high-density configurations, the search performance of traditional hash tables is significantly affected by frequent conflicts, and the search time shows a clear upward trend. In contrast, since the improved PTHash completely eliminates hash conflicts during the construction phase, its search time is almost unaffected by changes in data density and always maintains stable constant time performance. In most test configurations, the search speed of perfect hashing is better than that of traditional methods, showing higher response efficiency and lower latency fluctuations, especially at optimization level -O2, load factor When searching for a specific data point, the search speed is more stable and faster. In embedded scenarios with high real-time requirements, such as fast CAN message distribution and multi-protocol data indexing, this advantage can significantly improve the operating efficiency and stability of the entire system.

[0070] Further analysis showed that When the compilation optimization level is -O2 and inline optimization is enabled, the search path of the traditional hash table is more complex, the execution path has more branch judgments and memory accesses, the instruction disorder and branch prediction error rate increase, and to a certain extent, the uncertainty of its search delay is increased. In contrast, the PTHash search path is simple, without branch judgments, and can be easily optimized by the compiler into an efficient instruction stream. Therefore, the search performance at this optimization level is particularly outstanding. Overall, in application scenarios that are sensitive to latency, such as CAN message distribution, embedded protocol mapping, and real-time data scheduling, the perfect hashing scheme not only has a better average search time, but also shows significant advantages in search stability, which can effectively improve the data access efficiency and real-time response capabilities of embedded systems.

[0071] In the present invention, the core improvements include: First, the improved perfect hash function design. This invention makes a key improvement to the PTHash algorithm, eliminating the dense bucket identification and tilted hash processing steps that have high computational and storage overhead in traditional solutions. The sorting method uses dual-pivot quick sort, and no longer stores every h(x,s) value. By choosing a suitable constant c and a high load factor This design significantly reduces the memory usage and computational complexity on the embedded platform while ensuring the search time complexity is O(1).

[0072] Second, we optimize the balance between search performance and implementation complexity. Compared to existing methods like PTHash, this technology uses a computationally simpler hash function and employs a compressed storage scheme optimized specifically for MCUs, incorporating bit-packed array technology to compress and store critical index and reverse lookup table data. While maintaining high query efficiency, this technology effectively reduces code implementation complexity and system space overhead, making it particularly suitable for resource-constrained embedded environments.

[0073] The above are only specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed by the present invention should be covered by the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A perfect hash fast search method for embedded systems, characterized in that: The process includes a construction phase and a search phase, wherein the construction phase includes: Step S1-1: Map the static key set to multiple buckets through a hash function; Step S1-2: Arrange all buckets in descending order of size; Step S1-3: assign a unique guide value to each bucket, generate a conflict-free hash position and mark the occupied state; Step S1-4: Create the original index of the reverse lookup record key; The search phase includes: Step S2-1: Calculate the initial hash value of the input key and determine the bucket it is mapped to; Step S2-2: Obtain the guidance value of the bucket determined in step S2-1 and calculate its position; Step S2-3: Return the real index value corresponding to the position through reverse table lookup.

2. The perfect hash fast search method for embedded systems according to claim 1, characterized in that: In step S1-1, the number of barrels Determined by the following formula: Where c is an adjustable constant and n is the number of bonds.

3. The perfect hash fast search method for embedded systems according to claim 2, characterized in that: The adjustable constant c is set to 3.0, and the loading factor in the construction phase is The value is 1.

0.

4. The perfect hash fast search method for embedded systems according to claim 1, characterized in that: In step S1-2, the buckets are sorted in descending order using a dual-pivot quick sort algorithm.

5. The perfect hash fast search method for embedded systems according to claim 1, characterized in that: The step S1-3 includes: Step S1-3-1: Use the auxiliary array taken[0, ..., n-1] to record the occupied status of the positions in the key set key[n] = {0, ..., n-1}; select the seed s for the pseudo-random hash function h(x, s) to ensure that the keys in the same bucket have different hash values; Step S1-3-2: For each bucket Search for an integer reference value , so that all keys x in the bucket satisfy the position formula: Where, Indicates that the key value x is in the reference value The position value calculated under the conditions of Indicates guide value The hash value calculated under the seed s, Indicates guide value The hash value calculated under the seed s represents a modulo operation, where n is the number of keys. Indicates whether the calculated position value is occupied. A value of 1 indicates occupied, and a value of 0 indicates unoccupied. If the location is not occupied, the search is considered successful and the location is marked as occupied. Store in the Pilot array, otherwise try the next one value until all keys in the bucket are successfully placed.

6. The perfect hash fast search method for embedded systems according to claim 5, characterized in that: The step S1-3-2 also includes: establishing a reverse lookup table for each successfully placed key value and recording its position index.

7. The perfect hash fast search method for embedded systems according to claim 5, characterized in that: The pilot array and the reverse lookup table are stored using a fixed-length bit compression method.

8. The perfect hash fast search method for embedded systems according to claim 1, characterized in that: In the step S1 - 1 , a lightweight hash function h(x, s) is used to map the static key into a bucket. The lightweight hash function h(x, s) only includes integer XOR and shift operations.

9. The perfect hash fast search method for embedded systems according to claim 1, characterized in that: The search phase specifically includes: Step S2-1: Use the hash function to calculate the initial hash value corresponding to the input key x and determine the bucket it is mapped to; Step S2-2: Use fixed-length bit compression to query the index value corresponding to the bucket determined in step S2-1 , and has been stored in the Pilot array and saved by bit compression during the construction process; Step S2-3: Calculate the final position in the lookup table based on the initial hash value calculated in step S2-1, use fixed-length bit compression to query the reverse lookup table data at that position, and return the corresponding real index value.

Images