nemo insanely slow when many files in directory

[elmar roberg]

I will differ with some of the writers.
I too occasionally suffer from the problem. But suspect it is not OS, because whenever Nemo hangs, I simply open Double Commander and get instantaneous results.

[Petermint]

One experiment would be interesting. Open the System Monitor and watch the processor usage while nemo is running slow. Is Nemo locked into one processor?

If Nemo is developed using a modern programming language/approach, the thumbnail and other processes could happen in the background using other cores. I do not have a directory with enough files to create the problem. I do see a similar problem in other software where the SSD is faster than the software but the software uses only one core.

[Petermint]

Some replies suggest reorganising 50000 files into subdirectories. I have the slow Nemo problem with 50000 files organised into subdirectories, suggesting that the reorg is not a complete solution. Nemo 4.4.2.

The example I am looking at now has dozens of subdirectories with some of them having dozens of subdirectories. Nemo is using 147 MB. I do not know if it is caching everything or depending on the OS cache. There is 4 GB of memory spare for Nemo and OS caching.

Nemo 4 has an option in preferences to switch off thumbnails. I switched that off. Everything is less slow but still too slow.

Meld has a similar problem with displays of long file lists but that is understandable as Meld uses Python.

I do not know how Nemo is programmed. I wrote some C + GTK 3.22 code to do something similar. The GTK code for displaying lists of boxes is stupidly slow when there is more than 10 ~ 20 items in a list. I had to rewrite the code to maintain the lists outside of GTK and only use GTK to display a small selection within a list.

I developed the same display using a PHP Web page and it runs at full speed with no problems. If Nemo uses GTK 3, that could be one part of the problem.

[Petermint]

Another speed observation. I opened a directory I had looked at earlier. I selected some files. I had to wait 1~2 seconds before the mouse click resulted in a file display changing from the white unselected state to the green selected state. Nemo was performing a lot of work in the background despite having visited this directory before.

I deselected the list and selected the files a gain. This time it was instant. Nemo appears to spend a lot of time in the background doing something with the file list for the directory but then throws all that away when you move to a different directory. Nemo has to perform all the work again when you return to the fist directory.

Perhaps there a setting somewhere in Nemo to tell it to use more of the available Gigabytes or maybe a compile option.

[Petermint]

https://github.com/linuxmint/nemo/issues/1907
I switched off all Nemo extensions to get the old Nemo speed back but it is useless without some of those extensions.
I switched Fileroller back on without slowing down Nemo. I think Fileroller only does stuff when you right click.
I have no use for the share, colour, or emblem plugins and they seem to not make much difference.
That leaves the Nemo Media Columns plugin as the time waster.
More testing needed.

[smurphos]

That leaves the Nemo Media Columns plugin as the time waster.

It's definitely a time waster in my experience. If simple access to media info in the File manager is required and no need to sort by it I always recommend nemo-mediainfo-tab instead - https://launchpad.net/~caldas-lopes/+archive/ubuntu/ppa, which provides info on individual files via an extra tab on the Properties dialog.

[Petermint]

no need to sort

That is a sticking point. I sometimes need to sort media info. I will leave the extension installed and switched off. When I do need that data displayed and sorted, I will switch the extension on.

[fromWinToLin]

This issue still persists with the newly released Linux Mint 20, with Nemo version 4.6.4.

One of the big announcements for Mint 20 was improvements to Nemo, after years of complaints of sluggishness and struggling with larger directories (think albums and galleries.) They made some improvements to how thumbnails are generated and displayed, I believe.

The sad news is, Nemo still under-performs compared to Thunar, Pantheon Files, and Dolphin. To put it into perspective, Thunar instantly loads a large directory with many thumbnails, and there is no "shrinking" scrollbar to signify that it is still loading the folder's contents. Dolphin is the same. Pantheon Files is the same.

Nemo, on the other hand, even with thumbnails disabled, loads the same folder using more resources and more slowly. Many times it's still "loading" the contents, and you can see the scrollbar handle shrink in size as it updates the scrolling length of the folder. Sure, this is a matter of seconds, but it hiccups the user's workflow and fluidity. There is no true "snappiness" when using Nemo and larger folders.

I've already taken steps to switch over to Manjaro KDE edition exclusively on my laptop and desktop. I hate that I'm doing that because I've been a dedicated Mint user since it's earliest inception, even back when it was considered a fringe distro that "just has extra wallpapers and pre-installed codecs".

The file manager is probably the most frequently used software on a desktop operating system. Little annoyances and performance issues may seem insignificant at first, but they add up over time, and soon the annoyance becomes frustration, and now I feel like I have to switch. I had been using Thunar (on a Cinnamon desktop, which breaks integration), but I don't feel like doing that anymore.

Besides, this "upgrade" experience has been a nightmare. I followed the steps laid out exactly on the community site, written by clem. I even did a fresh install. Things are deprecated (cannot install fslint anymore), some things segfault that worked fine under Mint 19.x, and so on.

I also bumped into the issues laid out by another member, as seen at this link: Version 20 upgrade instructions are either incomplete, or upgrade process is dangerous

If you want to see something sobering, read the title of this old bug report, and then look at the year it was posted. The title is "Folder navigation is still slow" and it was posted in 2016. Then there's a reply four years later to "please retest on Linux Mint 20". And now the discussion is "closed", not allowing any more comments. Let that all sink in.

[Hugh Neutron]

I made a guide on how to switch Nemo for Caja because of this. Might wanna make a timeshift before you attempt this if you aren't a power user.

viewtopic.php?f=42&t=324887

[axisofevil]

I don't get any noticeable slowdowns on local directories - remote shares can be very slow, but I'm still using version 4.4.2 - perhaps 4.6.2 will be even faster?

Note - I do take the trouble to organise files into sub-directories, especially pictures/videos etc.
It helps to locate files that you forgot where you put them.

I find that if you have several thousand files in a single directory, then a GUI file manager isn't going to be much help, regardless of speed.

[Hugh Neutron]

IMO Nemo is a hopeless trainwreck and my guide to switch Nemo for Caja is the only way how to appreciate Cinnamon.

[Petermint]

Nemo with thumbnails switched off works instantly for me on directory with over 600 files. The thumbnails were never of much use. Pix is better for browsing with a useful thumbnail display.

0.5 seconds for directory with 5500 items.

LM 20 Cinnamon. Clean install. No paging. SSD.

[fromWinToLin]

I made a guide on how to switch Nemo for Caja because of this. Might wanna make a timeshift before you attempt this if you aren't a power user.

viewtopic.php?f=42&t=324887

I went over your guide. Does it work for you with Mint 20? Can you explain the part about "Libraries that need to be adjusted if you are not using Mint 19.2. Here is the package list for the files for non Mint 19.2 systems."

[fromWinToLin]

I find that if you have several thousand files in a single directory, then a GUI file manager isn't going to be much help, regardless of speed.

Nemo with thumbnails switched off works instantly for me on directory with over 600 files. The thumbnails were never of much use. Pix is better for browsing with a useful thumbnail display.

This is the type of "sour grapes" reasoning that I wish the open source community could view from the outside. Justifying software that under-performs or has inherent bugs, by telling the end-user to "change their workflow" or "thumbnails aren't that important" is a huge turn-off to people that just want to use their computers.

None of the above justifications or workarounds are needed for other file managers. Nemo is the issue, not the user, not large directories, not thumbnails, and certainly not the fact that you just want to use your computer and manage your files without having to find clever compromises.

I can tell you that Thunar handles large directories, even with thumbnails, like a champ. As does Dolphin: Bam! Contents instantly displayed, scrollbar doesn't shrink as more files are loading. No accidentally clicking on the wrong item because files are being "shuffled around" as more and more items are still being loaded. I must also mention that Nemo's performance issue is even more noticeable when you have other CPU intensive activities happening, whether in the background or copying files. The sluggishness is multiplied, and this is on a Core i7 CPU. Again, Thunar is always snappy, regardless.

Why oh why on Earth would I be seriously contemplating ditching Linux Mint, even though I've been a donator and ardent supporter and early user (wayyyyyy back). Nemo is a serious problem, and it's the default integrated file manager on Mint's flagship edition. It really saddens me. I just want to use my computer. In the meantime, I had to install and configure Thunar to bring back some snappiness to my workflow. Unfortunately, Thunar lacks in certain features (mainly, remember each folder's view options), and it doesn't integrate well into Cinnamon.

As far back as 2016, Nermo has been known to have sluggishness, hangs, and issues with large folders. Possibly even earlier than 2016.

[root]

I agree with fromWinToLin: nemo really works very slowly, and it doesn't matter [if there are a lot of files in the folder] or [just a few, but at this time it is running in dual-pane mode]; nemo in the background does some operations and the longer it is open, the more it hangs. It's easier to restart it in a couple of minutes ... although after a couple of minutes in dual-panel mode, it starts loading the system again. As an ordinary user, I don't understand what nemo is doing. And this also makes me very sad. fromWinToLin, I'm glad you have time to try kde. Perhaps this is the right decision. I also agree that closing the bug on github so soon was indecent / disrespectful on the part of xenopeek.

[axisofevil]

AFAIK I only have one directory > 1,000 items which nemo has no problem making thumbnails for in sub-second timescales.
There is no way my eyeballs can scan 1,000+ thumbnails in a sensible time.
That's why my data gets deliberately organised into sub-directories - so typically I only need to look at windows containing 10 - 100 thumbnails.

So Nemo isn't even slow, let alone "insanely" slow.

Anyway - doesn't the speed of the thumbnailer depend on mime-type and the underlying file system?

[SeancBKK]

I have a directory on a 2GB HD containing episode of TV shows plus 15 directories (one with almost 1000 TV shows in)

When I open the directory with Nemo it can take several seconds (10 or so) before I can scroll the list.

i5 4460 @ 3.20 Ghz with 16 GB Ram.

I'd love to know how to make things snappier.

[Petermint]

Switch off thumbnails. Switch off any add-on modules one at a time. I added then removed an add-on because it was too slow and Pix did the same thing many times faster.

[Lumikki]

This is maybe little bit offtopic the discustion, but it's still about Nemo speed issue. I'm still using old Linux Mint 19.2 Cinnamon, so don't know if this has been fixed.

While you can speed up Nemo little bit by disable some features, like counting files in subdirectory or thumbnails and so on. I have done this because I have a lot of files and subdirectories. Example I can have 100 subdirectories and everyone have between 100-2000 files.

There is one other performance issue in Nemo what I haven't seen here yet.

When moving large files in slower media, all Nemo related actions are very slow in that time. I transfer often multible 1-10GB media files from computer to NAS (NFS). While files are moved just fine, the computers Nemo related actions are very slow while this is happening. Example if you try open small textfile while file is transfered it can take very long time to open. I'm talking like 30-60 second just to open small textfile. If I open first the program from menus and use it's own open file feature, then it's instant open. But clicking Nemos interface it's very slow. I have notice that when the file transfer ends and second file starts to transfer, in that moment Nemo can do other tasks fine. But not while it's transfering file.

PS: Also Nemo's displayed file transfer speed seem to be based reading speed of file, not writing speed of file. This cause situation where Nemo is often stuck longer time in 99%, because while transfer bar is full (file readed in buffers?), it's still writing the file.

[AZgl1800]

I recently needed to copy 500gB of music files from one SSD to another one for a friend.

Originally started out using 19.3 Cinnamon with NEMO.
NEMO crapped out somewhere in the middle of that process.

as this laptop has two SSDs in it, and the OEM factory one is Win10, I rebooted into Win10 and formatted the target SSD so it was fresh.

I then copied 5 top folders at a time using TERACOPY and Win10 just did what I wanted it to do.
took about 2 hours, as both SSD drives were in USB adapters.