nemo significantly slower opening folder content

[howdev]

 * Nemo version (3.8.5)
 * Is issue with filemanager nemo
 * Distribution - Mint 19
 * Graphics hardware *and* driver (unrelated)
 *  64 bit

Issue This issue has been reported prior to Mint 18. Nemo open folders very slow. slower than Nautilus. much slower than Thunar. We expected the issue to be resolved in Mint 19, but still hasn't

Steps to reproduce Open nemo filemanager open some folder with contents. Especially can be test with /usr/bin directory. While Thunar opens instantly, there is a significant delay with nemo. to browse any folder with low item count still can see blank page then folders showing.

Expected behaviour instant show of folder contents

Other information

[mtwebster]

I can't agree with the nautilus comparison. Testing side-by-side, using the same style view they appear to me nearly the same. Both programs load their list view fairly quickly, and the icon view slowly. One difference is that nautilus uses the list view as its default, whereas nemo uses the icon view. This can be changed in the first tab of preferences.

Additionally, the number and type of extensions in use can vastly affect load times.

Efforts are being constantly made to improve these speeds. We're aware of thunar's performance, but it's not trivial to just say 'do it the way they do it' and snap our fingers.

[howdev]

Although you may not agree with nautilus comparison. many have complained nemo is slower than nautilus. I continuously click on the the sidebar shortcuts they both use about the same CPU load but nemo is slower in refresh visually. Thunar uses the much less CPU.

I made the test in the past, I disabled extensions and made no difference

[donlencho]

Since upgrading to Mint 19 (and now using Nemo 3.8.5), handling files in folders with a large number of files has become practically impossible, it uses one CPU to almost 100% to make any action (moving a file, creating a folder, ...) and can take up to 5-10 seconds to respond. Not sure this is the behaviour you are referring to, but maybe in part. I'll also react to #1902.

[howdev]

@donlencho Is not that serious with me where it uses 100% CPU but it does use alot when you browse folders. Not only high CPU load but visually slow. It is terrible to use when you are working on projects where you browse to many levels of subdirectories, I need to wait for folder to appear before clicking on it.

[howdev]

@mtwebster There are certainly many ways of doing things. The disappointment is after several major updates to Linux Mint there is no improvement of nemo's performance, not even to know what the issue is causing the slowness. Perhaps to do with the way gtk3 works.

[brownsr]

@howdev @donlencho Is there any thing you can do to help pin down where the problems you experience are ? So far you have identified 1) folders with a very large number of files 2) folders with many levels of subdirectories. Could you try, for example, a) disabling plugins, actions [edit, plugins] b) turning off thumbnails c) turning off folder counting [edit, preferences] and feed back if any of those make a difference. Similarly clarify what other preferences you might be using, such as tooltips and try changing those modes d) say if you get differences with different types of nemo view e) clarify what types of disk storage you are using, and how full you are running the disks

Regards

Simon

[howdev]

@brownsr The issues is not about many subfolders. The slowness is from loading folder contents whether they are files or folders. It is slow to display even the content only contain few items. Plugins disable tested before no difference.

GTK3 had a similar performance issue in the past with slow appending liststore. Someone suggested to use insert_with_valuesv instead. This may have to do with the way the model is populated for the iconview

And by the way I think this may have to do with sorting of the model as well. The populate and sorting of the model needs to be investigated.

[howdev]

https://stackoverflow.com/questions/3547743/gtktreeview-insert-update-performance-penalty-because-of-sorting

This is another problem I found on is to do with sorting in treeview. The sorting is to do with model and regardless of the view whether is treeview or iconview.

[donlencho]

Not sure we are talking about the same problem, as said before. I'll keep posting in #1902 instead. The problem for me is not immediate, when the system starts, it's fine (well I'm not talking about a speed contest between file managers, I'm not testing others).

[howdev]

you may say can't compare gtk2 and gtk3 app, but I just installed Thunar 1.8 is gtk3 and still as fast as Thunar gtk2 @mtwebster therefore should investigate the way Thunar does it. There is serious problem the way nemo does the iconview with the model

[andrewufrank]

I have serious difficulties with opening folders which are on a mounted separate disk. Nemo works fast on opening one of two external disk, but not the other. The entries in fstab are:

/dev/mapper/london--vg-additionalSpaceAF /home/frank/additionalSpace ext4 rw,relatime,data=ordered 0 0
/dev/mapper/london--vg-scratchAF /home/frank/Scratch ext4 rw,relatime,stripe=4,data=ordered 0 0

Nemo goes to 100% cpu only on one folder in this second disk. What information could I provide to help tracing this problem? What could be different in this folder from the others?

[NikoKrause]

First I would eliminate any hardware issues, e.g. try different cables. Does it happen with other file managers, e.g. nautilus.

[mtwebster]

Does this folder have a lot of pictures or other file types that have a thumbnail generated?

Try a couple things:

This gets rid of existing thumbnails (in case there's an issue with one that's being hung on) rm -rf ~/.cache/thumbnails (if you get a permission error, use sudo)

and/or

Try disabling thumbnailing: Preferences->Previews->Show Thumbnails - Never

Ensure you've got a new instance of nemo:

nemo --quit
nemo

Also, you can try disabling any extensions temporarily (Edit->Plugins, lower section) and again, restart.

[andrewufrank]

Thank you for the advice - nothing helps. No thumbnails in the file, not shown anyhow; disabled all extensions (nothing was present beyond the defaults).

Most surprising, if I open the folders from outside by unfolding them in the same windows, no undue delays occur. it is only in this folder for one folder, if it is opened (not unfolded), then nemo goes into 100 % cpu. What could be special about this folder (all others in the same folder open ok)?

[mtwebster]

Open a terminal in that folder, run ls -la - is there anything weird in there? Strange owner, permission bits, recursive links?

The fact it opens ok from the parent folder makes me think there's something wrong maybe inside one of the children of problem folder. Under normal circumstances, a view's 'directory' doesn't delve deeper than one layer deep of children by default (you get 'deep' counts only when doing things like right-click->properties or copy/move operations). Though I'd think no matter how you view the folder, you'd run into the problem (whether expanding from the parent or some other way).

Regardless, check the members of the folder as mentioned, and one deep in any child folders. Does this happen in the icon view also? Also, what version of nemo is this and what distro are you on?

[csgrad52]

I have hundreds of folders and nemo takes roughly 20 seconds to respond after start. The only thing that works for me (Mint Linux 19.1, Nemo 4.0.6) is edit-preferences-plugins- then under extensions disable nemo media columns. No thumbnails but nemo it is very responsive now in all folders.

[mindinsomnia]

Add my name to the list of 'Nemo is slow and getting slower'.

I got a folder with around 10,000 files in it. It opens almost instantly on Windows 7/Windows 10 and displays thumbnails instantly too. On Nemo, it very slowly adds thumbnails to the file browser, and before even displaying all of the files, it maxes out CPU usage of one core and eventually becomes completely unresponsive and must be 'Force Quit'. I know 10,000 files is a lot of files, but on a fast 8 core CPU, an M.2 SSD, and with 32GB's of RAM, and high end GPU, I expect to at least be able to open the folder and display all of the files in it. And when the performance on Windows 7/10 is so much better for this kind of thing, almost near instant results, I can't help but think Nemo must be doing something very inefficiently.

Mint 19 was meant to improve this, but from what I've seen so far, it seems like it's actually slower and worse. It was slow before, but this behaviour of slowing down to the point of becoming completely unresponsive is new. Don't know what to suggest folks, but IMO, performance improvements for Nemo should be the number 1 priority right now above literally anything else.

[shred]

The bug hits me as well... I have a photo folder containing several thousands of JPEG spread over about a dozen of subfolders. What I want to do is use Nemo for browsing the photos, and copying some of them into a different folder. It's supposed to be rather an easy task for a file manager. However, the more photo folders I browsed into, the slower Nemo gets. As soon as I unfocus the Nemo window, Nemo consumes 100% CPU for several seconds (up to minutes), and all Nemo windows become unresponsive.

I used gdb and backtracked the Nemo process when it happened. It turns out that the stack is filled with some 10,000 (!) recursive calls to gtk_css_node_ensure_style().

#0  0x00007ffff7998641 in gtk_css_node_is_last_child (node=0x555556247410) at gtkcssnode.c:281
#1  lookup_in_global_parent_cache (decl=0x555555c3d700, node=0x555556247410) at gtkcssnode.c:320
#2  gtk_css_node_create_style (cssnode=0x555556247410) at gtkcssnode.c:366
#3  gtk_css_node_real_update_style (cssnode=0x555556247410, change=19335741440, timestamp=0, style=0x555555d1f430) at gtkcssnode.c:425
#4  0x00007ffff7997494 in gtk_css_node_ensure_style (cssnode=0x555556247410, current_time=current_time@entry=15547745218) at gtkcssnode.c:1007
#5  0x00007ffff7997467 in gtk_css_node_ensure_style (current_time=15547745218, cssnode=<optimized out>) at gtkcssnode.c:1003
#6  gtk_css_node_ensure_style (cssnode=0x5555562472a0, current_time=current_time@entry=15547745218) at gtkcssnode.c:1003
#7  0x00007ffff7997467 in gtk_css_node_ensure_style (current_time=15547745218, cssnode=<optimized out>) at gtkcssnode.c:1003
#8  gtk_css_node_ensure_style (cssnode=0x5555562474f0, current_time=current_time@entry=15547745218) at gtkcssnode.c:1003

[... truncated recursive calls to gtk_css_node_ensure_style() ...]

#45980 gtk_css_node_ensure_style (cssnode=0x555559209710, current_time=current_time@entry=15547745218) at gtkcssnode.c:1003
#45981 0x00007ffff7997467 in gtk_css_node_ensure_style (current_time=15547745218, cssnode=<optimized out>) at gtkcssnode.c:1003
#45982 gtk_css_node_ensure_style (cssnode=0x555559209550, current_time=current_time@entry=15547745218) at gtkcssnode.c:1003
#45983 0x00007ffff7997467 in gtk_css_node_ensure_style (current_time=15547745218, cssnode=<optimized out>) at gtkcssnode.c:1003
#45984 gtk_css_node_ensure_style (cssnode=cssnode@entry=0x5555589bb4e0, current_time=15547745218) at gtkcssnode.c:1003
#45985 0x00007ffff799767e in gtk_css_node_ensure_style (current_time=<optimized out>, cssnode=0x5555589bb4e0) at gtkcssnode.c:1033
#45986 gtk_css_node_get_style (cssnode=0x5555589bb4e0) at gtkcssnode.c:1033
#45987 0x00007ffff7af7391 in gtk_style_context_lookup_style (context=context@entry=0x555556137d70) at gtkstylecontext.c:494
#45988 0x00007ffff7ac12c3 in gtk_render_icon_surface (context=0x555556137d70, cr=0x555555dee850, surface=0x5555585ef400, x=37, y=8) at gtkrender.c:1159
#45989 0x00005555556551a1 in ?? ()
#45990 0x0000555555683625 in ?? ()
#45991 0x0000555555684458 in ?? ()
#45992 0x00007ffff7b9cd94 in gtk_widget_draw_internal (clip_to_size=1, cr=0x555555dee850, widget=0x55555610c150) at gtkwidget.c:7032
#45993 gtk_widget_draw_internal (widget=widget@entry=0x55555610c150, cr=cr@entry=0x555555dee850, clip_to_size=clip_to_size@entry=1) at gtkwidget.c:6970
#45994 0x00007ffff797ff50 in gtk_container_propagate_draw (container=container@entry=0x55555613ddb0, child=0x55555610c150, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3850
#45995 0x00007ffff798001d in gtk_container_draw (widget=0x55555613ddb0, cr=0x555555dee850) at gtkcontainer.c:3670
#45996 0x00007ffff7ad1d7f in gtk_scrolled_window_render (gadget=<optimized out>, cr=0x555555dee850, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>, data=0x0) at gtkscrolledwindow.c:2102
#45997 0x00007ffff7985231 in gtk_css_custom_gadget_draw (gadget=<optimized out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at gtkcsscustomgadget.c:159
#45998 0x00007ffff798a10a in gtk_css_gadget_draw (gadget=0x555555f4c4f0, cr=0x555555dee850) at gtkcssgadget.c:885
#45999 0x00007ffff7ad0085 in gtk_scrolled_window_draw (widget=<optimized out>, cr=<optimized out>) at gtkscrolledwindow.c:3029
#46000 0x00007ffff7b9cd94 in gtk_widget_draw_internal (clip_to_size=1, cr=0x555555dee850, widget=0x55555613ddb0) at gtkwidget.c:7032
#46001 gtk_widget_draw_internal (widget=widget@entry=0x55555613ddb0, cr=cr@entry=0x555555dee850, clip_to_size=clip_to_size@entry=1) at gtkwidget.c:6970
#46002 0x00007ffff797ff50 in gtk_container_propagate_draw (container=container@entry=0x555555d162a0, child=0x55555613ddb0, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3850
#46003 0x00007ffff798001d in gtk_container_draw (widget=0x555555d162a0, cr=0x555555dee850) at gtkcontainer.c:3670
#46004 0x00007ffff7b9cd94 in gtk_widget_draw_internal (clip_to_size=1, cr=0x555555dee850, widget=0x555555d162a0) at gtkwidget.c:7032
#46005 gtk_widget_draw_internal (widget=widget@entry=0x555555d162a0, cr=cr@entry=0x555555dee850, clip_to_size=clip_to_size@entry=1) at gtkwidget.c:6970
#46006 0x00007ffff797ff50 in gtk_container_propagate_draw (container=container@entry=0x555555d142a0, child=0x555555d162a0, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3850
#46007 0x00007ffff798001d in gtk_container_draw (widget=0x555555d142a0, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3670
#46008 0x00007ffff7930f08 in gtk_box_draw_contents (gadget=<optimized out>, cr=0x555555dee850, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>, unused=0x0) at gtkbox.c:448
#46009 0x00007ffff7985231 in gtk_css_custom_gadget_draw (gadget=<optimized out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at gtkcsscustomgadget.c:159
#46010 0x00007ffff798a10a in gtk_css_gadget_draw (gadget=0x555555840200, cr=0x555555dee850) at gtkcssgadget.c:885
#46011 0x00007ffff79338b5 in gtk_box_draw (widget=<optimized out>, cr=<optimized out>) at gtkbox.c:457
#46012 0x00007ffff7b9cd94 in gtk_widget_draw_internal (clip_to_size=1, cr=0x555555dee850, widget=0x555555d142a0) at gtkwidget.c:7032
#46013 gtk_widget_draw_internal (widget=widget@entry=0x555555d142a0, cr=cr@entry=0x555555dee850, clip_to_size=clip_to_size@entry=1) at gtkwidget.c:6970
#46014 0x00007ffff797ff50 in gtk_container_propagate_draw (container=container@entry=0x555555d10250, child=0x555555d142a0, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3850
#46015 0x00007ffff7a72a8e in gtk_notebook_draw_stack (gadget=<optimized out>, cr=0x555555dee850, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>, unused=0x0) at gtknotebook.c:2515
#46016 0x00007ffff7985231 in gtk_css_custom_gadget_draw (gadget=<optimized out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at gtkcsscustomgadget.c:159
#46017 0x00007ffff798a10a in gtk_css_gadget_draw (gadget=gadget@entry=0x5555558ad1e0, cr=cr@entry=0x555555dee850) at gtkcssgadget.c:885
#46018 0x00007ffff7935088 in gtk_box_gadget_draw (gadget=<optimized out>, cr=0x555555dee850, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at gtkboxgadget.c:512
#46019 0x00007ffff798a10a in gtk_css_gadget_draw (gadget=0x55555583d050, cr=cr@entry=0x555555dee850) at gtkcssgadget.c:885
#46020 0x00007ffff7a752c4 in gtk_notebook_draw (widget=<optimized out>, cr=0x555555dee850) at gtknotebook.c:2530
#46021 0x00007ffff7b9cd94 in gtk_widget_draw_internal (clip_to_size=1, cr=0x555555dee850, widget=0x555555d10250) at gtkwidget.c:7032
#46022 gtk_widget_draw_internal (widget=widget@entry=0x555555d10250, cr=cr@entry=0x555555dee850, clip_to_size=clip_to_size@entry=1) at gtkwidget.c:6970
#46023 0x00007ffff797ff50 in gtk_container_propagate_draw (container=container@entry=0x555555af6440, child=0x555555d10250, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3850
#46024 0x00007ffff798001d in gtk_container_draw (widget=0x555555af6440, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3670
#46025 0x00007ffff7930f08 in gtk_box_draw_contents (gadget=<optimized out>, cr=0x555555dee850, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>, unused=0x0) at gtkbox.c:448
#46026 0x00007ffff7985231 in gtk_css_custom_gadget_draw (gadget=<optimized out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at gtkcsscustomgadget.c:159
#46027 0x00007ffff798a10a in gtk_css_gadget_draw (gadget=0x555555c0ce00, cr=0x555555dee850) at gtkcssgadget.c:885
#46028 0x00007ffff79338b5 in gtk_box_draw (widget=<optimized out>, cr=<optimized out>) at gtkbox.c:457
#46029 0x00007ffff7b9cd94 in gtk_widget_draw_internal (clip_to_size=1, cr=0x555555dee850, widget=0x555555af6440) at gtkwidget.c:7032
#46030 gtk_widget_draw_internal (widget=widget@entry=0x555555af6440, cr=cr@entry=0x555555dee850, clip_to_size=clip_to_size@entry=1) at gtkwidget.c:6970
#46031 0x00007ffff797ff50 in gtk_container_propagate_draw (container=container@entry=0x555555adb3e0, child=0x555555af6440, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3850
#46032 0x00007ffff7a81e40 in gtk_paned_render (gadget=<optimized out>, cr=0x555555dee850, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>, data=0x0) at gtkpaned.c:1818
#46033 0x00007ffff7985231 in gtk_css_custom_gadget_draw (gadget=<optimized out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at gtkcsscustomgadget.c:159
#46034 0x00007ffff798a10a in gtk_css_gadget_draw (gadget=0x555555c0cc80, cr=0x555555dee850) at gtkcssgadget.c:885
#46035 0x00007ffff7a81ce5 in gtk_paned_draw (widget=<optimized out>, cr=<optimized out>) at gtkpaned.c:1782
#46036 0x00007ffff7b9cd94 in gtk_widget_draw_internal (clip_to_size=1, cr=0x555555dee850, widget=0x555555adb3e0) at gtkwidget.c:7032
#46037 gtk_widget_draw_internal (widget=widget@entry=0x555555adb3e0, cr=cr@entry=0x555555dee850, clip_to_size=clip_to_size@entry=1) at gtkwidget.c:6970
#46038 0x00007ffff797ff50 in gtk_container_propagate_draw (container=container@entry=0x555555745400, child=0x555555adb3e0, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3850
#46039 0x00007ffff798001d in gtk_container_draw (widget=0x555555745400, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3670
#46040 0x00007ffff7930f08 in gtk_box_draw_contents (gadget=<optimized out>, cr=0x555555dee850, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>, unused=0x0) at gtkbox.c:448
#46041 0x00007ffff7985231 in gtk_css_custom_gadget_draw (gadget=<optimized out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at gtkcsscustomgadget.c:159
#46042 0x00007ffff798a10a in gtk_css_gadget_draw (gadget=0x555555c0ca80, cr=0x555555dee850) at gtkcssgadget.c:885
#46043 0x00007ffff79338b5 in gtk_box_draw (widget=<optimized out>, cr=<optimized out>) at gtkbox.c:457
#46044 0x00007ffff7b9cd94 in gtk_widget_draw_internal (clip_to_size=1, cr=0x555555dee850, widget=0x555555745400) at gtkwidget.c:7032
#46045 gtk_widget_draw_internal (widget=widget@entry=0x555555745400, cr=cr@entry=0x555555dee850, clip_to_size=clip_to_size@entry=1) at gtkwidget.c:6970
#46046 0x00007ffff797ff50 in gtk_container_propagate_draw (container=container@entry=0x555555adb200, child=0x555555745400, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3850
#46047 0x00007ffff7a81ed0 in gtk_paned_render (gadget=<optimized out>, cr=0x555555dee850, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>, data=0x0) at gtkpaned.c:1832
#46048 0x00007ffff7985231 in gtk_css_custom_gadget_draw (gadget=<optimized out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at gtkcsscustomgadget.c:159
#46049 0x00007ffff798a10a in gtk_css_gadget_draw (gadget=0x555555c0c900, cr=0x555555dee850) at gtkcssgadget.c:885
#46050 0x00007ffff7a81ce5 in gtk_paned_draw (widget=<optimized out>, cr=<optimized out>) at gtkpaned.c:1782
#46051 0x00007ffff7b9cd94 in gtk_widget_draw_internal (clip_to_size=1, cr=0x555555dee850, widget=0x555555adb200) at gtkwidget.c:7032
#46052 gtk_widget_draw_internal (widget=widget@entry=0x555555adb200, cr=cr@entry=0x555555dee850, clip_to_size=clip_to_size@entry=1) at gtkwidget.c:6970
#46053 0x00007ffff797ff50 in gtk_container_propagate_draw (container=container@entry=0x555555b28140, child=0x555555adb200, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3850
#46054 0x00007ffff798001d in gtk_container_draw (widget=0x555555b28140, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3670
#46055 0x00007ffff7a0bd48 in gtk_grid_render (gadget=<optimized out>, cr=0x555555dee850, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>, data=0x0) at gtkgrid.c:1713
#46056 0x00007ffff7985231 in gtk_css_custom_gadget_draw (gadget=<optimized out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at gtkcsscustomgadget.c:159
#46057 0x00007ffff798a10a in gtk_css_gadget_draw (gadget=0x5555558a0e20, cr=0x555555dee850) at gtkcssgadget.c:885
#46058 0x00007ffff7a0cc85 in gtk_grid_draw (widget=<optimized out>, cr=<optimized out>) at gtkgrid.c:1722
#46059 0x00007ffff7b9cd94 in gtk_widget_draw_internal (clip_to_size=1, cr=0x555555dee850, widget=0x555555b28140) at gtkwidget.c:7032
#46060 gtk_widget_draw_internal (widget=widget@entry=0x555555b28140, cr=cr@entry=0x555555dee850, clip_to_size=clip_to_size@entry=1) at gtkwidget.c:6970
#46061 0x00007ffff797ff50 in gtk_container_propagate_draw (container=container@entry=0x555555718360, child=0x555555b28140, cr=cr@entry=0x555555dee850) at gtkcontainer.c:3850
#46062 0x00007ffff798001d in gtk_container_draw (widget=0x555555718360, cr=0x555555dee850) at gtkcontainer.c:3670
#46063 0x00007ffff7bab4a6 in gtk_window_draw (widget=0x555555718360, cr=0x555555dee850) at gtkwindow.c:10420
#46064 0x00007ffff7b9cd94 in gtk_widget_draw_internal (clip_to_size=<optimized out>, cr=0x555555dee850, widget=0x555555718360) at gtkwidget.c:7032
#46065 gtk_widget_draw_internal (widget=0x555555718360, cr=0x555555dee850, clip_to_size=<optimized out>) at gtkwidget.c:6970
#46066 0x00007ffff7ba6030 in gtk_widget_render (widget=widget@entry=0x555555718360, window=0x555555776980, region=<optimized out>) at gtkwidget.c:17542
#46067 0x00007ffff7a50999 in gtk_main_do_event (event=0x7fffffffd5f0) at gtkmain.c:1838
#46068 gtk_main_do_event (event=<optimized out>) at gtkmain.c:1685
#46069 0x00007ffff7741a39 in _gdk_event_emit (event=event@entry=0x7fffffffd5f0) at gdkevents.c:73
#46070 0x00007ffff7752766 in _gdk_window_process_updates_recurse_helper (window=0x555555776980, expose_region=<optimized out>) at gdkwindow.c:3852
#46071 0x00007ffff7753936 in gdk_window_process_updates_internal (window=0x555555776980) at gdkwindow.c:3998
#46072 0x00007ffff7753af4 in gdk_window_process_updates_with_mode (recurse_mode=<optimized out>, window=<optimized out>) at gdkwindow.c:4193
#46073 gdk_window_process_updates_with_mode (window=<optimized out>, recurse_mode=<optimized out>) at gdkwindow.c:4164
#46074 0x00007ffff73323dd in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#46075 0x00007ffff7345983 in ?? () from /lib64/libgobject-2.0.so.0
#46076 0x00007ffff734eaaa in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#46077 0x00007ffff734f0a3 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#46078 0x00007ffff774ad93 in _gdk_frame_clock_emit_paint (frame_clock=<optimized out>) at gdkframeclock.c:640
#46079 0x00007ffff774b53d in gdk_frame_clock_paint_idle (data=0x55555579de10) at gdkframeclockidle.c:459
#46080 0x00007ffff7735bac in gdk_threads_dispatch (data=0x5555580b4b40) at gdk.c:755
#46081 0x00007ffff724eb31 in ?? () from /lib64/libglib-2.0.so.0
#46082 0x00007ffff724e06d in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#46083 0x00007ffff724e438 in ?? () from /lib64/libglib-2.0.so.0
#46084 0x00007ffff724e4d0 in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#46085 0x00007ffff7420d25 in g_application_run () from /lib64/libgio-2.0.so.0
#46086 0x00005555555911ff in ?? ()
#46087 0x00007ffff6afc413 in __libc_start_main () from /lib64/libc.so.6
#46088 0x000055555559124e in ?? ()

This is all I could figure out due to my very limited GTK and gdb skills.

It seems that Nemo is mostly busy computing CSS stuff. I don't know though why it gets worse and worse the more image folders I have visited.

[shred]

Addition: I have tried different themes (Arc-Darker, Mint-Y, Adapta-Nokto), but the issue persisted, so it does not seem to be related to the theme used. It rather seems to be the way Nemo uses GTK3, as if each icon shown adds another CSS layer (and thus another CSS parent) to the stack.

[mindinsomnia]

I tried to time Windows 7 to see how long it takes to open and load a folder with 12,000 photos in it and display the thumbnails but unfortunately the bugger is too quick for me and I can't tap the timer button on my phone fast enough to keep up with it, it's probably less than 0.2 seconds or so. That's on an SSD with 500MB/sec read/write.

Meanwhile, Nemo on the other hand, simply can't open the folder without crashing, and that's after a minute or two of trying to load all the icons into view. This really is a problem. This is on the same computer too (dual booted), but the sad part is, Windows 7 is on a slower SSD, Mint is on the faster M.2 SSD, with 3500MB/sec read/write speed.

Shred sounds like he's onto something with the CSS.

[flansuse]

I've tried every suggestion in this thread, but nothing makes a difference. Nemo simply performs poorly. It takes long to list the contents of a folder with many files, even with thumbnails disabled. If I open and close the same folder within seconds, it still goes through the same "refresh" process of slowly displaying all the contents.

However, with Thunar, the same exact directory lists all its contents IMMEDIATELY. There are no "accidental clicks" in Thunar because all the items display immediately and they do not "shuffle around" as more icons are being displayed. The scrollbar in Thunar never "shrinks", as compared to Nemo which has a scrollbar that shrinks and shrinks because it's still in the process of listing all of the files.

It's night and day. I love Mint 19, but I can't stand to use Nemo. It's sad because the file manager is an integral part of any desktop session.

Mint 19.1

Nemo 4.0.6

Thunar 1.6.15

Fully updated system.

[PungieEC]

Nemo is just too slow and performs poorly. I sit with some folders with a few hundred photos within and scrolling / copy / cut / paste actions is a nightmare. It literately becomes unresponsive for 10 seconds at a time.

I really hope the developers will prioritize this as their number 1 bug fix, otherwise the best solution is to use another file manager with each new release of Mint. I'm currently looking at other file managers as I can't wait 10 seconds at a time per copy / cut / paste action.

[flansuse]

"I really hope the developers will prioritize this as their number 1 bug fix, otherwise the best solution is to use another file manager"

Agreed. It's so bad that I installed Manjaro (KDE) on my other computer, and I might end up leaving Mint. This is too important, as dealing with files and directories is probably one of the most common usage of a desktop distro, second only to using a web browser.

Thunar? INSTANT listing, even of many files and large directories.

SpaceFM? INSTANT listing, even of many files and large directories.

Dolphin? INSTANT listing, even of many files and large directories.

Nemo? Horrendous.

Yet simply using another file manager isn't a great solution, as you lose some integration with the desktop, and the visual layout of Nemo is excellent.

[donlencho]

Unfortunately, this was also my "solution". I'm sorry I couldn't help find the source of the problem and I understand it's difficult to solve for the developers if the cause is not clear, but this is precisely what made me switch to another desktop environment: I get behaviour in Nemo that I can't predict and reproduce if I try to! Another bug I get is also the same kind of strange behaviour: #1401 (it's been closed but unsolved). I haven't really tried using another file manager in Mint. It's sad, because apart from that, Mint is ideal for me. I still run it on a PC I don't use for work, and I know I just have to kill Nemo (killall nemo) once in a while to restart it, then it's fine, until it's not anymore...

[shred]

Well, I think the cause is rather clear (see my posting above). I rather guess the problem is that no core developer has the time to look into it. (Sadly I cannot help, as this problem exceeds my GTK knowledge by far.)

I have switched to Thunar in the meantime. But I would love to return to Nemo, as I like its design and its integration into Cinnamon.

[donlencho]

Right, sorry, I missed your post. Seems like a probable cause indeed.

[howdev]

Nemo 4.06 is still way faster than Nemo 3.x

[mtwebster]

Why wouldn't a developer want to deal with and respond to these posts? I can't imagine.

We did quite a bit last cycle improving performance, and you wouldn't believe the amount of time I've spent this cycle working on it (You wouldn't, I'm certain). I've targeted quite a number of places where I can significantly improve performance, but unfortunately it's not as obviously simple as it's been made out to be.

To a significant degree we're tied to a certain program 'model'. It's not trivial to rip that all apart and reconstruct it, but we've been doing it a little at a time, and will continue to do it. As an example, last dev cycle we reworked how spacing is calculated in the icon view. There's much more efficient use of space now, and it gives us an opportunity now to further simplify some ridiculously complicated layout code.

Another issue is that nemo is pretty popular because it's feature-rich. For instance, I could really speed up the detail/list view if I got rid of the expanders next to the folder names (and the entire functionality of being able to expand the view to see the contents of that folder), but then a lot of people would raise hell (rightfully so) for us removing it. I'm considering an option to disable it if desired, but I haven't decided for certain.

There are a number of other things I've targeted as well, but I've no idea yet what of this will make it in or not.

I'm sorry to say, but you guys are not the only users here. I'm not sure what you expect out of us. I apologize if for your particular workflow nemo performs unsatisfactorily. Be happy you have the option of other file managers. I don't want people jumping ship, obviously, but I'm also not that motivated by threads that devolve into this. We do what we can as we're able to.

You are not going to see nemo performing like thunar for 4.2. If this is unacceptable to you then so be it. All I can promise that it is being worked on, even if we're not participating in these fun threads and responding regularly.

Lastly, have you all evaluated this performance with all extensions disabled? (actions and scripts don't matter).

Thanks. I would be happy to see any hard data on the performance issues. Some tips/suggestions:

Kill nemo: nemo --quit

Then clear your disk cache (I've made an alias to keep this handy: sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

Then run nemo as: NEMO_BENCHMARK_LOADING=1 nemo <path-to-your-problematic-folder>

You'll get a few times printed out to the terminal. I'd be curious to see those times, along with pertinent info like how many files in the folder (reasonably exact please), are they mostly image files? Thumbnails enabled? Which view - list or icon. The more data the better, when I'm evaluating things, I look at those times in primarily four ways:

• cache cleared, list view
• cached, list view (just run nemo a second time without clearing the cache again)
• cache cleared, icon view
• cached, icon view

If there are lots of images I might blow away ~/.cache/thumbnails and check things out with it having to regenerate previews again.

Only if you guys are interested, nothing I'm doing hinges on feedback here, it would just be handy to have more test data (and situations I can reproduce for myself). Obviously this is all hardware-dependent, but useful info can still be gleaned.

[donlencho]

Thank you Michael for this reply and sorry if some comments were offensive or at least not very constructive. It's true that not seeing reactions from people involved can lead to thinking that devs are not reading this or "caring". It's difficult to understand how, as a simple user, you can help pinpoint a problem, so thanks you for your tips as well. I will try to report these stats here next time I run into a problem. I did notice improvement over time by the way, I remember in Cinnamon 3.2.something that when I selected files then deleted them, they were stored in RAM somehow (whenever I deleted files, their total size was added to the memory of the Cinnamon process). This did not happen when deleting folders. Anyway, this seems to have been fixed as I don't think it's happening anymore in 4.2 and now I notice only the Nemo process excessively growing in memory and not the Cinnamon process. I'll try to get you numbers and logs...

[MickJR-2019]

Hello Michael, I'm still on Cinnamon 19.1 so not sure if things might have changed in 19.2. Anyway, to add to this thread, I'd like to add my observations re Nemo performance.

I've just been helping my partner clear her phone of approx 17k photos and as part of the process I copied them off to a single folder on my laptop (Dell Latitude, i5, 8Mb Ram, SSD). Similar to above I had speed issues moving files around (using copy/cut and paste etc) and at times it was getting quite frustrating to the point of being unusable.

After a bit of Googling I decided to set 'Show Thumbnails' to 'Never' in File Manager Preferences / Preview and this made a massive difference just displaying the files. I haven't actually timed the difference but it is an order of magnitude better.

Another observation was that if I do a cut and paste to moves files from one folder to another, (I was doing this with 10k images), I noticed that CPU core usage would go up to 100% and stay there once the 'cut' was initiated and before the 'paste' was actioned. It would then drop back to normal once the process completed.

If I was to summarise this I would say that turning off thumbnails made a huge difference. It made displaying files much faster, and it stopped freezes and long delays occurring when trying to move files around. I'm not sure if this info is helpful as it's not exactly scientific, but if there's any particular user tests that you'd like me to try just let me know.

[dodona2]

Add my name to the list too. Thanks a lot in advance!

[flansuse]

Add my name to the list too. Thanks a lot in advance!

I've since switched to using Thunar as my file manager in Cinnamon (another great alternative is Elementary Files). Both are worlds faster (practically INSTANT) at displaying directories with numerous files, regardless of whether thumbnails are enabled or not.

I think this issue with Nemo is too deeply entrenched to be resolved any time in the near future, also considering this performance issue has existed for a long time already. (You can see old posts by other users on the Mint forums, for example.)

[petermoo]

Nemo 4.4.2 on LM 19.3 Cinnamon with latest updates. Nemo was slow at 19.0. From 19.0 to 19.3, I switched off icons, icon view, thumbnail generation, and followed every other tip. Nemo keeps slowing down. From my experience of writing C with GTK3, everything in GTK3 is insanely slow for any list with more than ten entries. To make my code work, I moved the list processing out of GTK back into C and used GTK only to display the current active elements in the list. I created my own scroll processing that adds entries to one end of the display and removes entries from the other end of the GTK display. The result was visibly faster with 20 ~ 30 entries. Scrolling through a list of 1000 entries dropped from over a minute to less than a second.

I am about to install Thunar as Nemo makes my whole computer unresponsive. The weird thing is the System Resources display says Nemo is using only a trivial amount of processor but nothing responds for 2 ~ 3 seconds.

[petermoo]

I disabled all extensions and restarted. The response time often improves after a restart. Restarting with no extensions made it extra fast. Unfortunately Nemo with no extensions is almost useless to me.

I will experiment with one extension at a time. Where do we report problems with extensions?

The few extensions I use should not do anything in most directories Does Nemo run the extensions immediately or deferred or in a separate thread or only for selected file types?

[petermoo]

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.

[petermoo]

The following comment is interesting. There is an alternative to Nemo Media Columns and it does not create the problem although it is not useful for me.

I am leaving Nemo Media Columns installed and disabled. That produces no overhead outside of the startup. I can the enable the extension on the few occasions I need it.

[MartinX3]

I don't have the plugin Nemo Media Columns, but it creates thumbnails here. Weird.

Edit: Ah, the package nemo-media-columns isn't installed. But I have thumbnail creating and slow downs as well. It helps me to remove the cache folder in m home directory, until it creates again enough thumbnails to slow down.

[mtwebster]

The media columns plugin slows things down because it's written in python, and it's doing a lot of IO-intensive stuff when it runs. It provides extra data columns for the list view that you can turn on (things like image size, media encoding type, etc...). If you only use the icon views, there's no reason to have this enabled.

The entire reason we made the plugin management tab was so some of these could be disabled when or if they weren't necessary. I'm not going to judge performance based on extensions being enabled, particularly that one.

We're in the middle of another round of performance improvements in nemo, hopefully we'll see some improved results soon.

[mtwebster]

fyi, a couple of performance improvements were just implemented:

https://github.com/linuxmint/nemo/issues/2291#issuecomment-631210884

[howdev]

version 4.6 is much slower than 4.4. 4.6 as slow as 3.x

[iriki]

This is the beauty of Linux. I'm facing this issue while inventorying personal photos and videos and moving to Thunar made a world of difference. Thanks

[raveninthetardis]

So, I have a new install of Ulyssa (just days old without much use) and when using Nemo to move images about (drag and drop) in a directory with only tens of images (though subdirectories have hundreds) I get pauses of maybe 5-8 seconds when selecting single files in preparation to drag them during which one CPU core is maxed out and the rest almost idle - and the operation cannot complete until I wait for the maxed out core to become idle again. Does anyone have any practical suggestions to improve Nemo's performance in respect of this? It's a problem that has affected me on multiple machines, over several Mint versions and for friends when I turn them on to Mint it remains one of their few complaints they have once they get used to basic system administration after having used Windows.

My basic config from screenfetch is:

OS: Linuxmint 20.1 ulyssa Kernel: x86_64 Linux 5.4.0-65-generic Uptime: 31m Packages: 2375 Shell: bash 5.0.17 Resolution: 1920x1080 DE: Cinnamon 4.8.6 WM: Muffin WM Theme: Adapta-Nokto (Adapta-Nokto) GTK Theme: Adapta-Nokto [GTK2/3] Icon Theme: Mint-Y-Dark-Sand Font: Ubuntu 10 Disk: 133G / 466G (30%) CPU: Intel Core i3-8100 @ 4x 3.6GHz [36.0°C] GPU: Mesa Intel(R) UHD Graphics 630 (CFL GT2) RAM: 2387MiB / 15864MiB

I only have the default emblems, color switcher, share and file roller extensions listed and enabled so I haven't knowingly changed anything in respect of plugins.

My disk is a basic NVME WD Blue and tests out OK so that shouldn't be an issue.

and I wonder what is Nemo doing exactly at that time since the directory I'm operating on has 58 images in it, there are 13 subfolders (visible as icons but not showing the images within them) and 550MB along with 755 images in total. Once the lagging happens it seems that every subsequent operation will do it while you're inside that folder though when I exited that folder it seemed to lose the lag on every operation. Is it doing something with items in subfolders that it doesn't need to perhaps? Something to do with moving thumbnails about in what appears to a layperson to be not very challenging conditions seems to get it into a state which it doesn't recover from until you exit that directory (or possibly restart Nemo). Does Nemo calculate or perform some manipulation on the non-visible subdirectory's thumbnail cache when you move the file or files into it? If so, does it have to? Might it not be better if that's happening to just flag it as changed and re-thumbnail it when we actually finally go inside it to view the thumbnails? I'm sorry if these are silly questions. I'm just spit-balling with my zero understanding of what's going on.

[Jeremy7701]

I don't suffer slowdowns on image files even with images in a 200+ sub-directories. However, I do run (on a daily basis), via cron find ~/.cache/thumbnails/ -type f -mtime +12 -exec rm {} \; This removes cached thumbnails which are older than 12 days, thereby reducing the cache size and presumably the cache lookup time. It suits me - obviously if you have a large turnover of image files, it might not suit everyone.

[raveninthetardis]

Thank you for posting that suggestion Jeremy. So, I ran that command and then took two minutes of traversing two directories, one called temp inside the directory with 58 images in it and subdirectories with 755 images and 550MB, opening images in image viewer to examine them, close image viewer and then dragging the image into temp. I did this with about 30 of the images until I arrived at the same broken state as before. Each time I would close the image viewer I'd return to Nemo still present underneath and observe one core maxed out. Interestingly, all I'd have to do is maximise or even minimise Nemo to cause this to happen again. I wonder what is present in my install that could be doing that if yours is fine. Do you open xviewer to view images as you move them about? Is there a way to debug this issue or pinpoint what's causing it that anyone could suggest? System Monitor just has the Nemo process using all of a single CPU thread. Nothing else is showing up as using CPU at that point.

[mtwebster]

@raveninthetardis if you're primarily using the 'icon' view, it could be this: https://github.com/linuxmint/nemo/issues/2472

It's (finally) been fixed but we haven't gotten it out in a point release yet. I'm trying to get one out today possibly.

If you are using the icon view, try list view instead (if possible with whatever you're doing).

[raveninthetardis]

@mtwebster Icon view is how I choose what I want to move about but the task is not time critical so I'm happy to wait for the fix (and happier that there might be one, thanks to you chaps). I'm sure that if this is the long-standing problem that's been responsible for Nemo repeatedly "pausing" with a maxed-out thread in icon view and it's fixed it'll make a lot of people very happy. Thank you for taking the time to verify and investigate it.

[Jeremy7701]

Have to admit that I don't do a lot of moving of images - typically I might upload a few dozen images into a sub-directory and view them with xviewer or GIMP (sometimes) - I occasionally edit (without moving) to produce a cut-down version. I then periodically will use digikam - see below.

If you are doing a lot of image processing, long term, then it might be worth using some proper image management software. For example digiKam https://www.digikam.org/ stores information such as thumbnails, metadata in a database and allows easy preview etc and might be a better way to deal with lots of images. "digiKam can easily handle libraries containing more than 100,000 images"

[fredmenez]

Maybe offtopic but I experienced another use case scenario suggesting that nemo is not the culprit :

OS: Linux Mint 20 Ulyana

1. Connect an android phone via USB and select file transfer
2. Browse a DCIM subdirectory with many photos and using thumbnails icons view
3. After a minutes of loading various directories with photos nemo starts not responding (freezing)

When restarting it nemo takes about 15 to 20 seconds to appear, and it has difficulty displaying the contents of a directory.

Following the suggestions posted here I had hoped to see some improvments with thunar but it displayed the same slowdowns.

Listing files from the terminal display no slowdowns.

When unplugging the phone from the USB port : the slowdowns both disappeared from nemo and thunar.

During the slowdown the following error messages appeared :

Called "net usershare info" but it failed: 'net usershare' returned error 255: net usershare: cannot open usershare directory /var/lib/samba/usershares. Error No such file or directory Please ask your system administrator to enable user sharing.

You must override the default 'drag_data_delete' handler on GtkTreeView when using models that don't support the GtkTreeDragSource interface and enabling drag-and-drop. The simplest way to do this is to connect to 'drag_data_delete' and call g_signal_stop_emission_by_name() in your signal handler to prevent the default handler from running. Look at the source code for the default handler in gtktreeview.c to get an idea what your handler should do. (gtktreeview.c is in the GTK source code.) If you're using GTK from a language other than C, there may be a more natural way to override default handlers, e.g. via derivation.

[ranolfi]

Add my name to the list of 'Nemo is slow and getting slower'. (...) performance improvements for Nemo should be the number 1 priority right now above literally anything else.

This is still as true now as it was more than two years ago when you wrote it and I could not agree more.

[flansuse]

Add my name to the list of 'Nemo is slow and getting slower'. (...) performance improvements for Nemo should be the number 1 priority right now above literally anything else.

This is still as true now as it was more than two years ago when you wrote it and I could not agree more.

I'm being very serious when I say I switched to KDE on Manjaro because of this. We use the file manager every day. We rely on it to handle directories with few files or numerous files, and to handle it consistently without mis-clicks due to "populating" the view. Even with thumbnails and extensions disabled (which isn't a "solution" regardless), it's the same issue as it was years ago, as early as 2018, and maybe even earlier.

For all intents and purposes, the file manager practically is the operating system when it comes to the end-user interacting with their computer. I'd argue the web browser perhaps more so, but the file manager is a close second.

Because of Nemo, and only Nemo, I have left my favorite Linux distro (Mint). I can't believe I reached that point. I migrated my two main computers to Manjaro KDE, and ever since then using my computers have been infinitely less frustrating.

I might revisit Mint and Cinnamon in the future one day, but I doubt it. From what I and many others have seen, it appears this is going to be a perennial issue with Nemo.

Nemo is simply sluggish. Milliseconds combine into seconds, and when you're dealing with that regularly while using the file browser, it negatively affects workflow.