Sushi fails to preview large shell script files, uses too much CPU
I have Sushi installed on a new Linux Mint 20.1 install. It's version 3.34.0-2, installed via the Mint Software Manager application. Nautilus version is 3.36.3.
Sushi is failing to show a preview of a couple of text-based large shell script "installer" files that I happen to have in my Downloads folder. And it almost locks up the Nautilus window, and uses a consistent 12.5% of a Ryzen 5 3500U (4-core, 8-thread) CPU that is usually idling around 2-3% with multiple applications and 30 tabs in a Chromium window.
One of the files that causes this is the installer for the Java-based jDownloader 2, the other is the installer for the Linux version of the Private Internet Access VPN client.
JD2Setup_x64.sh
pia-linux-2.6.1-05824.run
As you can see, one file has a ".sh" extension, the other has a ".run" extension. Both are executable shell scripts, and both are of course just plain text files internally. But they are huge. Bizarrely huge. They are 50MB and 73MB, respectively. So I'm not even going to attempt to submit them as attachments.
You can google "jdownloader linux installer" or "pia linux installer" to find them and download them for testing.
I tried just duplicating these files and renaming the duplicates to ".txt" and then Sushi of course successfully shows me the preview of the first part of the file within a couple of seconds, just like any other text file. But in the background, long after closing the Sushi preview window, the org.gnome.NautilusPreviewer
process continues consistently using 12.5% of the CPU. That's just... what? Why?
I attempted to open one of these huge text shell scripts in Xed, and it showed the first part of the file right away but had a progress bar across the top of the editor showing that it was going to take quite a long time to load the entire text file. So I assume that it would take maybe 10 or even 15 minutes for the Sushi process to stop using that 12.5% of my CPU, since like Xed it seems to also be attempting to load the entire file into memory. It's that slow even on a decent NVMe SSD.
All of this behavior seems completely irrational for what is supposed to be a "preview" plugin.
First of all, it makes Sushi seem extremely unstable, as if it's locking up just trying to show a preview window. It sits there and shows nothing, presumably until it has the chance to load the entire file for some reason. Unless you rename the files, in which case it obviously uses a different module or algorithm to quickly load the preview.
Nemo's preview plugin, in contrast, will at the very least display a window with a "Loading" spinner, so at least the user knows that something is happening.
Let's take the example of using "less" in a terminal to preview the contents of these same shell script files. It works instantly, because "less" doesn't try to load the entire file before showing me the first few dozen lines.
I feel like it's reasonable to expect a previewer plugin to be much smarter than this about quickly identifying whether a file is previewable at all, and certainly the first few kilobytes of a text file should be quite easily previewable in a few milliseconds. There's no good reason to be slower than "less" at reading out a text file.
Why is Sushi apparently trying to load the entire file? There should be limits placed on exactly how much of a file Sushi attempts to immediately load. You don't attempt to load an entire 1GB video file, right? You just read it off the disk on demand, starting at the beginning.
User feedback: Sushi needs to behave more like Apple's Quick Look and Nemo's preview extension, and always immediately bring up the preview window (with a "Loading" spinner if necessary) to show the user that it is actually trying to do something. Lack of immediate feedback for a user action is not good. It makes it seem like the preview function is simply locked up and failing to function. It makes Sushi feel "broken".
Rational use of time: Sushi needs to give up on previewing the contents after a reasonable (in human terms) amount of time. When I try to preview a large PDF or video or similar file via Quick Look from a slow drive, like a network drive that needs to wake up first, Quick Look is smart enough to just give up after a short time (less than 5-10 seconds or so) and just falls back to showing some generic information about the file rather than a full preview. Often, canceling Quick Look and trying again will result in the full preview now that the drive is responding better, but Quick Look knows to not keep trying forever. It will certainly not try to load a preview in the background for 15 minutes.
Cancel should be immediate: Sushi needs to immediately let go of trying to load a file if the user hits Space again to cancel, or moves to preview a different file. This does not appear to be happening in a timely manner.
I get the disturbing feeling that if the preview process was multi-threaded it would be maxing out my CPU instead of using exactly 1/8th of the total CPU (i.e., one thread). So that's lucky, I guess? But if this behavior isn't nipped in the bud before Sushi is properly multi-threaded for faster previews, it could be a serious problem.
I can be available to run some commands or try previewing other types of files if it would be of any help in trying to resolve this behavior.