In Thunar 1.6.11 the selection of multiple files is very slow. Steps to reproduce: 1. Open a directory containing more than 100 files (like "/usr/bin/") 2. Select the first file 3. Press Shift 4. Start selecting multiple files with down arrow key while holding Shift 5. Notice that speed of selection of new files slows down in geometric progression. After 100 files selection gets so slow that it would probably take an hour to select 300 files that way. The bug also affects the speed of moving multiple files from one directory to another using clipboard. The more files - the slower the speed. System information: - Debian 9 (stretch) - Thunar 1.6.11
Sorry, I can't reproduce with 1.6.12 nor current master (soon to be released as 1.7.0). Does it make any difference using another view (Icons, Detailed List, Compact List)? Can you reproduce this with other machine? Also try to kill thunar (pkill -i thunar), run it from terminal and check if any error is given.
I as well cannot reproduce this bug. Debian 9.2 Tested with thunar master and thunar 1.6.11
Andre, indeed, when I switch to the Icons view or Detailed list view the bug is not there. So it appears only in Compact list mode. Killing thunar and restarting it doesn't give any errors. Also, maybe I wasn't clear in the bug reproduction steps. You need to hold BOTH Shift and Down arrow buttons. Not to hold Shift and press Down multiple times. I reproduced this bug on another machine with completely different hardware. Although, on that machine, the speed of selection didn't lowered that much, but instead, the selection process appeared to be with pauses and then sudden selection of several files at a time to compensate the pause. And then it was a pause again and so on.
Hmm, still cannot reproduce in compact view :X The same happens on Shift + Right ? Maybe a memory / swap issue ? What is the output of "vmstat" ? How about CPU load ? Can you see the output of "top" during file-selection ?
I just checked "top" while selecting and found out that it's 96% CPU core load by "Xorg" process during selection and 10% by thunar. I have two cores x 3.3 GHz on this machine. Shift + Right gives the same CPU load, although the speed lowering is barely visible. It's most noticeable with Shift + Down. I tried the same Shift + Down in Blender, which has its own file opening interface and "Xorg" isn't loaded while selecting with Shift + Down. Also I had Linux Mint with Cinnamon and Nemo on this machine, things were smooth in there too. Vmstat gives this: r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 2636 653244 37828 2619348 0 0 219 257 785 82 22 2 76 1 0 Thank you for trying to help!
I have 4 Cores, 3,2 GHz here ... not that much different On both, thunar master and thunar 1.6.11 I have a similar result for "top": max 55%CPU Xorg / max 39%CPU Thunar Same for compact and icon-view. Much better for detailed view. For nemo compact view it looks much better: max 9%CPU Xorg / max 20%CPU Nemo .. my OS runs the processes on different CPUs. Possibly thunar requests more graphical refreshs than Nemo. Something which maybe could be improved. But why I don get the bug you report ? ... Regarding the CPU's we could check if the OS uses both of them on your system: When you are using "top", press "f" and select "P = Last Used Cpu" Than press "d" and than "q". Another test for the ram: trigger vmstat each second for 60 seconds: vmstat 1 60 And than reproduce the bug. For me "si" and "so" are always zero while selecting files with SHIFT+DOWN. Swap (si and so) are not used at all. Same for you ?
I did "top", "P = Last Used Cpu". My Xorg and Thunar use different cores. I guess the Thunar's sluggishness is caused by Xorg (max 98% load for me). But the funny thing: I never get Thunar's load as high as yours (39%) while holding shift+down. I get max 12%. Maybe that's the key to the unsolved mystery. vmstat 1 60: while holding Shift + Down si and so always show zero for me too.
Still could be caused by thunar, since I quess Xorg only reacts on "refresh"/"redraw" events of thunar. Could you try to install as well nemo and see if the bug is present there ? ( As well nemo has a cluster - view. Possibly Debian vs Linux Mint makes a difference )
For the clearer result I decided not to install Cinnamon. So I installed Nemo and launched it from Xfce. Switched to compact view. Selection with Shift + Down was very fast. CPU load: Xorg - max 15%, Nemo - max 16%. I think even if you don't get the sluggishness and Xorg 98% when using Thunar, still your numbers (max 55%CPU Xorg / max 39%CPU) for Thunar is pretty high. We are not playing 3D games, we are just selecting files... Imagine how that would look like on really old machines, where Xfce is popular due to its light "weight".
I agree that the weak performance compared to nemo is something we should look into for thunar. However it looks like there is a second, still unknown factor involved, which increases the Xorg load to 98% for you, making it hard to use, while for me ( and others ) the load still stays acceptable.
I think that Xfce is an awesome environment, looking forward to helping improve it. If I can do anything more to detect that second factor, just let me know. :-) Also, I'm going to reinstall Debian for other reasons, so I will use that to try to reproduce that bug on a freshly installed system without anything else installed, maybe that will help.
If you are brave, you could try to compile thunar from source ( you as well will need to compile exo from source ) ... you can get the code of both from here: https://git.xfce.org/ Thunar master ( and thunar 1.7 ) are using gtk3 instead of gtk2 .. however I would bet that the gtk version does not make a difference for the bug. For the first factor ( weak performance ) , the class "Thunar-abstract-icon-view" probably is the right places to search. "Thunar-abstract-icon-view" is the parent class of "Thunar-compact-view" and "Thunar-icon-view" which both are affected.
*** Bug 13698 has been marked as a duplicate of this bug. ***
Doh, much more work than I initially expected: - Rewrite of mayor parts of "thunar-launcher" was required - Completely dumped "thunar-template-action" which just was there to provide the "create File" submenu and iherited from GtkAction. Moved relevant stuff into thunar-context-menu If you are interested, here another working WIP snapshot: https://github.com/alexxcons/thunar/commits/MergeAllContextMenus3 (Better dont look at the code .. I need to tidy up. Commits to be squashed / reflogged) Nice sideeffect: This will fix the slowness on mutli-file-selection (Bug #14026), since no file/folder monitors are used on the "selected files" any more.
Crap, commented on the wrong bug ... cannot remove comment #14 :/ ... hope we will switch to gitlab soon. What I oroginally wanted to tell: This bug will be fixed as well by the patch for Bug #14410 (Comment 14) (still WIP, but if you like, you can already take a try)
If you want to take a try for that WIP branch: https://github.com/alexxcons/thunar/tree/MergeAllContextMenus5 Dont know why I was unable to reproduce before .. now I can easily reproduce: CPU load with thunar master: 100% - unresponsive after a few seconds CPU load with WIP branch ~65%, continues to scrolls smoothly Still not like nemo, though already much better. Probably related to all the actions which were automatically triggered "on selection change" before, in order to constantly update the different menu items. In the WIP branch all menus are just build "on request".
Fast forward 2020 I still can't reproduce: Thunar from git master, using Compact view, in /usr/bin, selected first file, press and hold shift and down. Thunar is using about 11% of CPU (4 cores here) and it's slow even after selecting 500+ files. Am I missing something?
Created attachment 9518 screenshot Real strange ... I just re-tried and got the worst performance ever ... 19 files selected, than total hang on 100% CPU :) That was icon view on some other folder, though I as well can reproduce with compact view on /usr/bin. Sooner or later I anyhow will apply my WIP branch to get rid of GtkAction/GtkUiManager ... so I guess it does not matter much.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/thunar/-/issues/180. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev