Nemo: High memory usage and frequent 1-2s lags in response when doing almost anything

[a-torgovitsky]

 * Nemo version (nemo --version)
nemo 3.8.4

 * Is issue with desktop or windowed nemo?
Both

 * Distribution - (Mint 17.2, Arch, Fedora 25, etc...)
Mint 19

 * Graphics hardware *and* driver used
NVidia Quadro P400
nvidia-driver-390
390.48-0ubuntu3

 * 32 or 64 bit
64 bit
 ```

**Issue**

Nemo windows show noticeable lags of 1-2s for many actions:
- Double clicking on a directory
- Clicking on a drop-down list
- Trying to close a window

No apparent pattern in directories for which this happens.

Also: Both nemo and nemo-desktop use a large amount of memory.
On a recent reboot:
nemo-desktop: 350 MB
nemo: 360MB (just a single window open)

**Steps to reproduce**

Open nemo, try to browse files or interact with it in general.


**Expected behaviour**

Based on previous installations, I expected Nemo to be quite responsive.
Also, I have never noticed it to be a memory hog.

**Other information**

When I try to start Nemo from the command line I get this warning message:

(nemo:7973): Gtk-WARNING **: 17:42:39.855: Failed to register client: GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to register client
```

Also, I have tried using Thunar and see no delay or lag at all.

EDIT: I tried creating a new user account. The problem does not appear in the new account, suggesting that this is something to do with settings at the user level.

[donlencho]

Since upgrading to Mint 19 (and now using Nemo 3.8.5), handling files in folders with a large number of files [i.e. 100-200] (at least that's where I notice the problem the most) has become practically impossible, it uses one CPU at 100% to make any action (moving a file, creating a folder, ...) and can take up to 5-10 seconds to respond to really basic things.
If there is a way I can provide more debugging info, let me know, I'm not sure where to look for this.

[howdev]

one of the way is to write a python code of icon view directory browser then compare with nemo and see if there is problem with gtk3 iconview or the way to load files to iconview

[donlencho]

Still trying to figure out what could be causing this and I'm guessing it's due to some memory filling up, because after a restart of Nemo, it's behaving normally for a while.

[a-torgovitsky]

I am seeing this problem using "list view" in nemo

[donlencho]

icon view for me.

[a-torgovitsky]

Do you get the problem in a fresh user account?

[donlencho]

I tried several things but it's really hard to investigate as this is not happening all the time and takes a while to manifest itself. When I start a session (mine or a fresh user), everything is fine. But after a while, things get slow, then slooooooowww.
And by things, I mean any action in Nemo, like clicking on a file to select it, scrolling, changing folder, dragging a file, anything.
This is probably something building up as I use the file manager, but I don't know what.
When it becomes unusable, I now just do a killall nemo then start it again and all is fine.

[a-torgovitsky]

My problem happens all the time.
Response is slow and memory usage is high even on a brand new session.

[mtwebster]

Have any of you tried clearing your thumbnail cache? rm -rf ~/.cache/thumbnails

Let me know also if when doing this you get an error (permission denied or such) - if that happens, run the command with sudo to force the issue.

[a-torgovitsky]

I tried that (did not need to elevate to root) and it did not have any effect.
I turned off thumbnails early in my install, so I only had about a dozen in there.

[a-torgovitsky]

Today I tried reverting my customized
~/.config/user-dirs.dirs
back to the default

This seems to have fixed my problem with the delayed response, as well as drastically reduced the memory usage of both nemo and nemo-desktop.

I have done some updates since I last checked this, but none involved nemo.
Also, this explanation would be consistent with not seeing similar behavior on a fresh user account.

[mtwebster]

Would you object to sharing that file? I'd like to see the scenario in action and at least try to come up with an explanation or reason. I'm mainly curious because there a number of XDG paths that we don't really use (not just nemo, the entire 'desktop') and actually utilizing one may be causing the issue.

[a-torgovitsky]

Sure, here it is:

# This file is written by xdg-user-dirs-update
# If you want to change or add directories, just edit the line you're
# interested in. All local changes will be retained on the next run.
# Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped
# homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an
# absolute path. No other format is supported.
#
XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Desktop"
XDG_TEMPLATES_DIR="$HOME/docs"
XDG_PUBLICSHARE_DIR="$HOME/"
XDG_DOCUMENTS_DIR="$HOME/docs"
XDG_MUSIC_DIR="$HOME/music"
XDG_PICTURES_DIR="$HOME/"
XDG_VIDEOS_DIR="$HOME/"

[RacerBen]

New user here, but I also believe this problem is related to customization. Since installing a few days ago I've been doing extensive tidying and reorganising of files / folders and running into this same issue where Nemo would decide at some point to start constantly freezing up for several seconds when trying to switch windows, drop files, etc.. The only way to continue working would be to not do anything for about 5 secs then try again.

I was using the "qob" theme, but since reverting back to "cinnamon" theme it's all working fine.

Hope this might give a clue as to the issue.

[dshanks01]

I've just seen something similar with nemo 4.0.6 under Mint 19.1, although the problem did not happen until my system (a laptop) had been running for several days. Lag was due to continuous swapping. Nemo-desktop process had 4.8G resident, 10.4G virtual memory allocated; continuously climbing. Killing the nemo-desktop process resolved the symptoms.

Unfortunately I can't describe steps to reproduce the problem. I've only seen it once since upgrading to Mint 19.1 and never saw it prior to Mint 19.1. I've used Mint/Nemo in various versions for years.

I'll report again if I can reproduce the problem on demand or if additional information is requested.

[a-torgovitsky]

Recently I installed Linux Mint 20 on the same machine.

Without remembering this issue, I went and customized my user-dirs.dirs directory.
Then I noticed laggy behavior with Nemo---not as bad as I remember from when I posted this originally---but still enough to be annoying.

After some serious deja vu, I finally remembered this issue I opened a couple of years ago. Reverted user-dirs.dirs back to its default. Now Nemo is very responsive again.

So I think this issue still persists in version 4.6.5.