search

sharksforarms / deku

Declarative binary reading and writing: bit-level, symmetric, serialization/deserialization
Apache License 2.0
1.05k stars 54 forks source link

Add no-assert-string feature #405

Closed wcampbell0x2a closed 2 months ago

wcampbell0x2a commented 5 months ago

When no-assert-string is enabled, remove string generation in .rodata section. When writing parsers made for embedded platforms that are limited in storage these strings add up when many assertions are added.

github-actions[bot] commented 5 months ago

Benchmark for e51d275

Click to view benchmark | Test | Base | PR | % | |------|--------------|------------------|---| | deku_read_bits | **1099.2±17.01ns** | 1144.4±14.90ns | **+4.11%** | | deku_read_byte | 23.2±0.43ns | **22.7±0.39ns** | **-2.16%** | | deku_read_enum | 9.4±0.16ns | 9.3±0.12ns | -1.06% | | deku_read_vec | 53.3±0.83ns | 53.3±0.72ns | 0.00% | | deku_write_bits | 113.0±1.29ns | **108.7±3.40ns** | **-3.81%** | | deku_write_byte | 140.3±6.10ns | **122.7±2.41ns** | **-12.54%** | | deku_write_enum | 92.7±6.25ns | **86.1±4.66ns** | **-7.12%** | | deku_write_vec | 3.1±0.03µs | 3.1±0.03µs | 0.00% |
github-actions[bot] commented 5 months ago

Benchmark for 7c221b9

Click to view benchmark | Test | Base | PR | % | |------|--------------|------------------|---| | deku_read_bits | 1124.9±13.34ns | **1109.6±18.58ns** | **-1.36%** | | deku_read_byte | 23.4±0.97ns | **22.5±0.42ns** | **-3.85%** | | deku_read_enum | 9.5±0.10ns | 9.5±0.07ns | 0.00% | | deku_read_vec | 53.8±0.46ns | 54.2±0.87ns | +0.74% | | deku_write_bits | 113.1±1.87ns | 111.8±8.35ns | -1.15% | | deku_write_byte | 124.1±4.25ns | 125.7±7.15ns | +1.29% | | deku_write_enum | 86.0±4.27ns | 87.0±4.84ns | +1.16% | | deku_write_vec | 3.2±0.04µs | **3.0±0.03µs** | **-6.25%** |
sempervictus commented 5 months ago

Wonder if some sort of rainbow table/heuristic dictionary or compression based approach would help provide middle ground for more usable string space with qualified lookup/decompression speed. Some sort of checksum dictionary stored in runtime might also be more efficient since its not really the bytes of the strings we're usually asserting but their equivalence to X or Y which matches pre-computed hashes.

wcampbell0x2a commented 5 months ago

Wonder if some sort of rainbow table/heuristic dictionary or compression based approach would help provide middle ground for more usable string space with qualified lookup/decompression speed. Some sort of checksum dictionary stored in runtime might also be more efficient since its not really the bytes of the strings we're usually asserting but their equivalence to X or Y which matches pre-computed hashes.

Interesting idea, it could return a hash of both the struct/enum and field which could be reversed at runtime if you wanted that information. That would take some design, this is easier for me to just turn on and not have extra bytes of data..