Excessive jshell imports

[dev747368]

Importing all the class names when you are creating the jshell instance (~2600 classes) causes some severe lag when executing even simple REPL statements (eg. "int i = 0;")

The REPL isn't even responsive for almost a minute after starting up because its processing the evals for currentAddress, etc, which each take several seconds. The async nature of the console make it confusing because your input is accepted, but nothing happens.

Maybe just import a few hand-picked packages?

[goatshriek]

Thanks for trying out the project, and even more for creating an issue for a problem! I've created the jshell-performance branch with changes related to this issue, starting with adding a timer for how long the auto-import takes to complete.

Filling the auto-import list with every class in Ghidra except for the ones that caused problems was an overzealous first approach. I've created a new auto-import list based on the imports used in the scripts included with Ghidra. It cut the auto loading on my jshell instance from 10 seconds to 5. If you want to try it out, you can overwrite the auto-import.xml file in the data folder of the installed extension with this one. I've also changed the default of the auto-importing feature to be off for all interpreters, so that this is something users must opt in to.

I haven't yet, but I'll add an initializing message and version banner to all of the interpreters, including JShell, which is printed when the interpreter is ready. This should at least give some indication to the user that the input is ready so that it is a little less of a mystery.

I haven't seen delays anywhere close to a minute delay with the current list though, which makes me wonder if something else is also happening to impact performance. Can you share any details on which JVM and JDK version you're seeing this on? Is the lag of the currentAddress updates causing a noticeable delay in just navigating the CodeBrowser?

You may already know this, but for others seeing this issue it is possible to disable the auto-loading on a per-interpreter basis. You can find the relevant options in the CodeBrowser (Edit->Tool Options) under the "Ruby Dragon Interpeters" section.

[dev747368]

re: startup time. I'm in a full Ghidra eclipse setup. Timing the startup of the tool and putting a "int i =0;" in the REPL to when I got back a REPL response, was 1 min 30 seconds-ish.
Yes, clicking in the listing caused extreme GUI lag, about 20 seconds per click (I'm guessing because of the setting of currentAddress)
I'm using corretto jdk 18. My machine is sufficient to do Ghidra development in Eclipse without any complaints.
Thanks for the pointer to the interpreter options. Turning that off got me to where I can use it.

[goatshriek]

One other suggestion as a stopgap is to make sure that the plugins for the other (non-JShell) interpreters are not enabled if JShell is the only one that you're using. You should see all of them in the File->Configure menu of the CodeBrowser under the "Core" category. You can quickly see which ones are enabled by which ones have icons on the toolbar as well.

Some of them create their interpreter and keep state updated regardless of if you've launched them yet. They are not all like that, and I'll change the ones that aren't lazily created to be lazy as part of this change, but in the meantime disabling the others may speed up your browsing experience some.

[goatshriek]

The latest release for Ghidra 10.3.3 includes the fixes described above.

I have not been able to reproduce the performance issues you described with a Release build of Ghidra. I'll use the plugin with a debug build of Ghidra to see if this reproduces what you're describing and update this issue with the results of that.