Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add no-assert-string feature#405

Merged
wcampbell0x2a merged 1 commit into
masterfrom
add-no-assert-string
Apr 29, 2024
Merged

Add no-assert-string feature#405
wcampbell0x2a merged 1 commit into
masterfrom
add-no-assert-string

Conversation

@wcampbell0x2a
Copy link
Copy Markdown
Collaborator

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.

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
Copy link
Copy Markdown
Contributor

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
Copy link
Copy Markdown
Contributor

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
Copy link
Copy Markdown

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
Copy link
Copy Markdown
Collaborator Author

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..

@wcampbell0x2a wcampbell0x2a added this to the 0.17.0 milestone Apr 10, 2024
@wcampbell0x2a wcampbell0x2a merged commit bf83f55 into master Apr 29, 2024
@wcampbell0x2a wcampbell0x2a deleted the add-no-assert-string branch April 29, 2024 22:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants