diff options
| author | blasty <blasty@local> | 2026-07-23 01:34:48 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-07-23 01:34:48 +0200 |
| commit | 7a47d42230d49f052b5599bb0b8f25cf71174436 (patch) | |
| tree | def9082289291714ba64272fd47f9c0f0b6625dd /docs/RPC.md | |
| parent | app: listing 'n' names the address (can name a bare/undefined byte) (diff) | |
| download | ida-tui-7a47d42230d49f052b5599bb0b8f25cf71174436.tar.gz ida-tui-7a47d42230d49f052b5599bb0b8f25cf71174436.tar.xz ida-tui-7a47d42230d49f052b5599bb0b8f25cf71174436.zip | |
perf: derive segment map from file_regions, not survey_binary (hex open ~3400x)
The slow hex load wasn't the byte reads (read_raw fixed those) -- it was
opening the pane at all: hex_model -> image_range -> sections called
survey_binary, which computes function counts/strings/stats and takes ~24s on
libcrypto, blocking the first hex open (and section_of/segment_bounds/
region_label in the listing).
sections/file_regions/image_range now share one cheap _segments source backed
by the injected file_regions tool (a plain segment walk, ~7ms), which gains a
name field so it fully replaces survey_binary for the segment map. Falls back
to survey_binary only if the tool is missing.
Measured (libcrypto): segment map 24240ms -> 7.1ms (~3400x); hex open goes from
~24s to ~11ms. Correctness verified (names, section_of/segment_bounds/
file_offset); hex+listing scenarios 24/0, full suite 123/1 flaky. Needs a
supervisor restart.
Diffstat (limited to 'docs/RPC.md')
0 files changed, 0 insertions, 0 deletions