Changing from compact view to list view or vice versa or pressing F5 in a directory containing many files freezes thunar

Follow-up to #1315 (comment 87110)

I tested this in a directory containing 20,000 images. Once the view has been changed, the cursor rotates indefinitely, thunar does something (given the cpu usage), and closing the window brings up the force close dialog.

version: git master 61e6cdf1 and 4.18.10

added 1. Performance label

changed the description

mentioned in issue #1315 (closed)

Finished up the replacement of GList in exo-icon-view (exo!74 (merged)), which makes using icon-view on 100k files much faster ... though sadly that does not fix this isssue.

I can reproduce the problem as well when e.g. switching from list-view to icon view. A trace seems to point to thunar_list_model_files_changed again.

Possibly only a matter of suppressing the file-changed signal during view-change. I'll look into it.

^C
Thread 1 "thunar" received signal SIGINT, Interrupt.
thunar_list_model_files_changed (folder=<optimized out>, files=0x555562c247a0 = {...}, store=0x555555ec9a50) at thunar-list-model.c:1413
1413	          if (G_UNLIKELY (g_sequence_get (row) == file))
(gdb) bt
#0  thunar_list_model_files_changed (folder=<optimized out>, files=0x555562c247a0 = {...}, store=0x555555ec9a50) at thunar-list-model.c:1413
#1  0x00007ffff7183540 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2  0x00007ffff7196afc in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3  0x00007ffff7198501 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x00007ffff719e186 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x00007ffff719e243 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x00005555555b60cb in _thunar_folder_files_update_timeout (data=0x5555559a2010) at thunar-folder.c:586
#7  0x00007ffff708202e in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x00007ffff707e0d9 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007ffff7081317 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff7081930 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff72b3b7d in g_application_run () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#12 0x000055555557ff44 in main (argc=2, argv=0x7fffffffe068) at main.c:86

added 5. Compact View 5. Icon View labels

closed with commit cf835363

Actually, the cause seems to be older. Found the problematic code at a commit, which I did myself 6 years ago : 6e2b1d76 Probably as well a problem for thunar 4.18.x

The offending line is a thunar_standard_view_reload(THUNAR_VIEW (object), TRUE); when the PROP_THUMBNAIL_DRAW_FRAMES property is set, which triggers a reload of each single file in the folder.

That is just total overkill ... we actually only want to redraw the icons. Fixed with above commit.

mentioned in commit 4fe08fa4

^ fixed as well for 4.18 branch

changed milestone to %4.18.11

Nice! Switching to the icon view still takes longer than switching to the compact view, while switching to the list view is almost immediate, but this has clearly fixed the problem. I think the orders of magnitude between the different views are about the same as I mentioned in exo!74 (comment 87584).

mentioned in issue #1340

Yea, there still is something which slows down icon/compact view a bit ... I opened #1340 to further investigate. From the first look, I suppose I will have to move the issue to exo later on

Reopening this issue, since the same call (in the end thunar_folder_reload (folder, TRUE) ) is done when pressing F5, resulting in the same freeze for icon/compact view.

The fix above for sure is correct, though it looks like there is even more to fix.

Oh yes, I'd also forgotten about F5!

reopened

changed title from Changing from compact view to list view or vice versa in a directory containing many files freezes thunar to Changing from compact view to list view or vice versa or pressing F5 in a directory containing many files freezes thunar

mentioned in merge request !445 (merged)

Gna, found out what is the problem … it's the usage of GList again, this time in Thunar.

A GList is used for the "files-added", the "files-removed" and the "files-changed" signals which I introduced not that long ago in e5b237d5

Note to myself for the future: Whenever files need to be stored in a container-format: Just don't use GList for that, but use GSequence or GHashTable instead.

This refactor got much bigger than I planned ... performance on F5 seems to be fine now in !445 (merged), though I did not have time yet to run the Wiki integration testcases on the branch to make sure everything else still works ... that will be next.

closed