search

rizinorg / cutter

Free and Open Source Reverse Engineering Platform powered by rizin
https://cutter.re
GNU General Public License v3.0
15.84k stars 1.15k forks source link

Cutter is slow with big binaries #498

Closed xarkes closed 5 years ago

xarkes commented 6 years ago

Currently working on a 17MB arm binary. It looks like everything is slow (seeking mainly).

xarkes commented 6 years ago

I suspect the navbar, maybe we should cap it to a maximum number of slices, or maybe rework the code for improvements.

thestr4ng3r commented 6 years ago

May be related: https://github.com/radare/radare2/issues/10162

ulidtko commented 6 years ago

I just loaded up a 45 MiB binary (static link + debuginfo)... 5 minutes later, had to abort the aaa phase and retry without analysis. This time, it loaded up, and aa'd reasonably fast — however, the Cutter process now shows a crushing RSS of 6 GiB o'ram.

Like, guys... if anyone would be willing to take on some heap profiling for this — it'd be shining cool to shave off some of this 13000% on-disk-binary→cutter-ram amplification!

xarkes commented 6 years ago

Yes of course, that's why this issue is opened. Ideally it would be great if you could share the binary, because that much RAM usage might be due to the analysis of your binary.

ulidtko commented 6 years ago

Well it's really nothing particularly special, just a statically linked C++ service with dwarf3 debuginfo and some LLVM instrumentation (fuzz+asan). Afraid I can't simply share it, since that's uhh company property; however I guess, pretty much any similar big binary will do.

ulidtko commented 6 years ago

The bare r2, btw, eats 2.2 GiB just on loading the same binary, with additional 1.5 GiB consumed after aa. The total 3.7 gig is considerably smaller that cutter's; so it seems there're ways to go.

xarkes commented 6 years ago

Thanks for clarifying.

thestr4ng3r commented 6 years ago

VisualNavbar now uses p- and works much faster.

domenukk commented 5 years ago

I ran into different performance issues when trying cutter against the teamspeak client for linux(x64) version 3.2.3 (unpacked from this archive).

While aaa took around 15 Minutes, which is totally fine by me, the normal use of Cutter keeps re-analysing things, seemingly in the foreground, for almost every mouse click. This blocks the whole UI. I've uploaded a demonstration video here although the screen record sadly didn't take up the spinning ball indicating processing.

It might be a good idea to do some of the processing later and render something already, without blocking the whole workflow.

xarkes commented 5 years ago

So I tried with latest version on master, and although the loading is still slow and the interface freezes a bit during loading, I can navigate in the binary very fluently. Notes:

ITAYC0HEN commented 5 years ago

Closing. It is not a specific issue which is focused or limited