Feature Request: Performance (Speedup of e.g. Scrolling) by Caching Results (e.g. Disassembly)

[Semnodime]

I just noticed that when scrolling down even just one single line

1. radare2 apparently doesn't cache anything
2. reads the mapped region again
3. calculates the disasm for a region that overlaps (close to 100%) what has previously been disassembled already

As a consequence, when showing 200+ lines of disasm, scrolling is slow, very slow.

Feature Request (for massive performance gain)

1. Cache disasm for all lines
2. If scrolling (the disasm offset) or code change did not invalidate the previously calculated disasm, display the cached result.
3. When scrolling to a "new location", only new instructions need to be recomputed.

[trufae]

Use panels, graph or the webui where things are cached. It's known behaviour, and it shuoldnt be slow as far as i know all O(1) bottlenecks have been fixed. So the result is not slow, but can be faster of course if caching the output like the mentioned frontends do.

Also, i assume you are talking about the visual mode, right?

[karliss]

Last time I checked it not only reads mapped region again but it reads 1024 bytes for each instruction, so for printing 200 lines as suggested above it would read 200KB mostly overlapping which can be very slow when using debug IO backends.

[trufae]

Thats exactly what core-block was about. But now every single read goes thru a large list of data structures and unnecessary operations just to get the data that is not cached by default (yes the io have an option to be flat and cached). And yep slow io backends are the main bottleneck on the whole thing but caching wont solve the problem of reading so much unnecessary data.