Ghidra slow when analysing.

[bukowa]

I have multiple programs in my project. I work on one when others are being analyzed. Ghidra can get really slow then (little thread stutters?). Is there any workaround?

[d-millar]

You could batch analyze them in headless mode.

[bukowa]

But it states:

While running, be aware that:
The Headless Analyzer may not run if the specified project is already open in Ghidra.

[d-millar]

True enough - I'll let other folks chime in on this, as it's not my area of expertise, but I think those may be your options.

[dragonmacher]

Another option to consider, if you have enough resources on your machine, is to create a second project for importing and analyzing binaries. You can have 2 Ghidras open at the same time, one pointing to the import project and one pointing to your actively working project. When you are done importing and analyzing, you can move the new binaries from the import project to the other project.

[bukowa]

This can work but I can already imagine some overhead with dependencies in the same project.
I am not sure about Ghidra architecture but is there any chance for some threading related work on this part to leave some resources free when analysis is happening?

[dragonmacher]

Ghidra is a highly multithreaded system in general. The analysis thread specifically is a single thread running in the background that will periodically push updates to the GUI.

Each non-trivial widget in the GUI is also multi-threaded. If you happen to have a large number of these widgets open, then the various threads all running when the analysis thread updates the GUI can cause sluggishness. The Symbol Table is an example of a widget that can cause the GUI to slow down with excessive analysis updates. If this happens to you, you can close the Symbol Table and you will not see this issue. This is just an example, but it applies to any of our threaded widgets that update when analysis is working.

[bukowa]

It would be beneficial to have a user action that allows freezing of UI updates in a program while it's open and being analyzed, as identifying the root cause of freezes and re-opening windows afterwards can be time-consuming?

[bukowa]

I am really not sure where the cause can be as sometimes it's just running fine.

[dragonmacher]

We attempt to fix issues like this as we find them. If there are repeatable slow downs, which implies an issue in our code, then we should be able to improve that. General sluggishness due to resource usage is harder for us to address.

It would be beneficial to have a user action that allows freezing of UI updates in a program while it's open and being analyzed

Interesting idea, but likely too hard for us to implement in our current architecture.

[astrelsky]

It is well known that ghidra is very slow at analysis. Even when analyzing small programs on a workstation with plenty of resources available it can take a few seconds (as opposed to milliseconds)

There are plenty of places I've wanted to point the finger at but I have no proof.

One of these places is the database implementation, specifically the lock mechanism, could be a read/write lock such that threads aren't almost always getting blocked when attempting to access the database since everything is always accessing it. But I have no proof.

There have been times where I considered this area was intentionally neglected so that the hip and cool analysis progress bar could be seen. Otherwise it would just go away so fast you'd never see it.

[astrelsky]

For reference, since I'm not just full of 💩, I just ran analysis on a 5MB program and it took 12.5 minutes. The longest analyzer was CreateFunction taking 3.3 minutes.

It was actually the Decompiler switch analysis taking 7.5 minutes. It still shouldn't take that long and the CreateFunction one is suspicious.