Closing "Launching Tool" Splash page

[lmstearn]

Windows 11 Pro, 24H2, 26100.3323, Ghidra 11.31, no additional tools/extensions.
When closing the "Launching Tool" dialog after using it on a project item in the Project dialog, there is the following prompt
"Do you really want to cancel Launching Tool?"
On either clicking "Yes" or "No", the Codebrowser page comes to the front, and is not cancelled. The Project dialog remains untouched as well. Can't say this is a bug as not sure integrity of the setup here has been compromised somehow, or what the intended behaviour is after closing the Splash page.
Thanks.

[dragonmacher]

There are various tasks performed when opening the tool. My guess is that one or more of those tasks is not checking for the user cancellation request. Fixing this would require a non-trivial effort. Each non-responsive spot would have to be updated to take a task monitor and know how to check it periodically. This usually isn't an issue, since the tool typically opens in a couple seconds. Are you seeing something different, where the tool takes excessively long to open?

[astrelsky]

There are various tasks performed when opening the tool. My guess is that one or more of those tasks is not checking for the user cancellation request. Fixing this would require a non-trivial effort. Each non-responsive spot would have to be updated to take a task monitor and know how to check it periodically. This usually isn't an issue, since the tool typically opens in a couple seconds. Are you seeing something different, where the tool takes excessively long to open?

10.96 seconds just starting ghidra and opening the Code Browser without a program. Even longer if it decides it wants to create stupid bundles or compile the sleigh spec.

[dragonmacher]

Full Ghidra startup, with restoring Code Browsers and possible program state can certainly take a long time. OP suggested that just opening a new Code Browser with program from the Front End may be taking a long time as well. I've looked into both cases a few times over the years. I even have a branch somewhere where I updated all related code paths to take a Task Monitor. As one can imagine, updating the framework in this way was annoyingly difficult, since it was not built with this in mind originally. My branch has aged off, mostly since this never seemed like a high enough priority. If the people deem it worthwhile, I can always revisit this work.

[lmstearn]

Definitely low priority if not trivial, at least it's out there if someone else complains.

[astrelsky]

Full Ghidra startup, with restoring Code Browsers and possible program state can certainly take a long time. OP suggested that just opening a new Code Browser with program from the Front End may be taking a long time as well. I've looked into both cases a few times over the years. I even have a branch somewhere where I updated all related code paths to take a Task Monitor. As one can imagine, updating the framework in this way was annoyingly difficult, since it was not built with this in mind originally. My branch has aged off, mostly since this never seemed like a high enough priority. If the people deem it worthwhile, I can always revisit this work.

No, this did not include startup. I only timed opening the Code Browser. I worded it poorly, my mistake. I meant from a fresh startup, but not including the initial startup time. I only timed the time it took from clicking the dragon icon to open the Code Browser to when it the Code Browser finished opening.

If I close the Code Browser and reopen it, it takes around 3.7 seconds. I would say that is acceptable, but I still don't understand why it needs so much time to open.

[dev747368]

I'm seeing a few low hanging fruit in the Plugin.init() phase of the codebrowser tool startup.
On my machine, the FidPlugin is taking 900ms'ish, and the JythonPlugin is taking another 800ms'ish. Then it tails off with the DTM Plugin and DTM Preview Plugin taking 400 + 100 ms'ish, and then down in the weeds after that.

I'm guessing that some of the work done in those plugin.inits() could be refactored in some way to get the tool opened quicker.

[astrelsky]

I'm seeing a few low hanging fruit in the Plugin.init() phase of the codebrowser tool startup.
On my machine, the FidPlugin is taking 900ms'ish, and the JythonPlugin is taking another 800ms'ish. Then it tails off with the DTM Plugin and DTM Preview Plugin taking 400 + 100 ms'ish, and then down in the weeds after that.

I'm guessing that some of the work done in those plugin.inits() could be refactored in some way to get the tool opened quicker.

Out of curiosity, is it loading and initializing all plugins regardless of whether or not they are enabled and added to the tool?

[dragonmacher]

The 'correct' solution would be to perform the various startup tasks in phases. If running in dev mode, then languages sometimes get compiled when the tool is opened as well. Layering the phases would at least give better feedback to the user, with more time to cancel loading. I suspect that there are also some plugins that may be misbehaving. Also to be explored is deferred initialization of slow plugins.
'
@astrelsky All plugins are discovered when Ghidra starts. When the Code Browser opens, only active plugins should be initialized.