You are not logged in.
- Topics: Active | Unanswered
#1 2025-11-23 09:31:36
- tgirod
- Member
- Registered: 2018-09-16
- Posts: 13
[solved] extremely slow qt app
I've noticed recently that some GUI apps are very slow on my system, and I think it is linked to QT. For example, when opening MusicBrainz Picard, it takes several seconds to open a folder selection popup, and I can hear my laptop struggling.
I ran strace to get a glimpse at what's happening. Here, I am launching picard, opening the folder selection dialog, selecting a folder with a few files in it and closing the application - minus the time spent reaching the button with the mouse of course.
> time strace -c -o trace picard
________________________________________________________
Executed in 18.67 secs fish external
usr time 12.89 secs 695.00 micros 12.88 secs
sys time 1.00 secs 931.00 micros 1.00 secs
### trace summary
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- -----------------------
46,37 0,068197 2 25844 25536 access
12,99 0,019102 53 355 ppoll
7,55 0,011109 2 4962 read
6,14 0,009035 10 855 52 futex
3,55 0,005228 1 3455 313 newfstatat
3,07 0,004509 2 1977 162 openat
2,92 0,004291 36 119 munmap
2,30 0,003381 3 950 mmap
1,75 0,002569 2 1076 write
1,74 0,002552 10 239 getdents64
1,73 0,002545 0 2819 10 lseek
1,71 0,002519 1 1847 close
1,53 0,002243 0 2640 fstat
1,36 0,002003 3 659 544 readlink
0,83 0,001216 1 1112 1039 ioctl
0,71 0,001051 4 221 brk
0,54 0,000792 2 349 38 statx
0,52 0,000769 34 22 clone3
0,42 0,000621 8 73 rt_sigprocmask
0,36 0,000532 2 190 mprotect
0,34 0,000501 62 8 fallocate
0,25 0,000372 18 20 madvise
0,24 0,000347 43 8 fdatasync
0,16 0,000242 242 1 execve
0,14 0,000205 102 2 sched_setscheduler
0,09 0,000131 1 81 rt_sigaction
0,08 0,000114 3 30 sendmsg
0,06 0,000084 3 24 24 mkdir
0,04 0,000061 2 25 fstatfs
0,04 0,000058 1 32 fcntl
0,04 0,000052 2 19 getpid
0,03 0,000050 50 1 mknodat
0,03 0,000048 24 2 connect
0,03 0,000039 9 4 2 recvmsg
0,03 0,000039 9 4 rename
0,03 0,000037 9 4 socket
0,02 0,000036 18 2 socketpair
0,02 0,000033 6 5 unlink
0,02 0,000030 15 2 sched_get_priority_max
0,02 0,000030 15 2 sched_get_priority_min
0,02 0,000026 26 1 open
0,02 0,000026 4 6 memfd_create
0,01 0,000022 5 4 gettid
0,01 0,000022 5 4 getrandom
0,01 0,000021 2 9 prlimit64
0,01 0,000018 4 4 flock
0,01 0,000017 2 8 uname
0,01 0,000017 1 10 geteuid
0,01 0,000014 2 5 ftruncate
0,01 0,000013 1 7 getuid
0,01 0,000013 2 6 getgid
0,01 0,000012 2 6 getegid
0,01 0,000012 3 4 pipe2
0,01 0,000011 3 3 getsockname
0,01 0,000009 4 2 pread64
0,01 0,000009 1 7 1 recvfrom
0,00 0,000007 0 8 4 linkat
0,00 0,000006 2 3 sendto
0,00 0,000005 5 1 arch_prctl
0,00 0,000005 5 1 rseq
0,00 0,000004 0 5 mremap
0,00 0,000004 4 1 listen
0,00 0,000004 4 1 set_tid_address
0,00 0,000004 4 1 set_robust_list
0,00 0,000002 1 2 wait4
0,00 0,000001 0 4 fchmod
0,00 0,000001 0 2 sched_getaffinity
0,00 0,000000 0 1 bind
0,00 0,000000 0 2 setsockopt
0,00 0,000000 0 1 vfork
0,00 0,000000 0 1 getcwd
0,00 0,000000 0 6 4 prctl
0,00 0,000000 0 1 inotify_add_watch
0,00 0,000000 0 1 inotify_rm_watch
0,00 0,000000 0 1 epoll_create1
0,00 0,000000 0 1 inotify_init1
------ ----------- ----------- --------- --------- -----------------------
100,00 0,147078 2 50170 27729 totalI'm a bit shocked by the amount of syscalls happening here - especially failed access syscalls. Is it normal for a pyqt application? Any idea where I should look to investigate further?
Last edited by tgirod (2025-12-17 14:16:54)
Offline
#2 2025-11-23 10:08:06
- tgirod
- Member
- Registered: 2018-09-16
- Posts: 13
Re: [solved] extremely slow qt app
Follow-up: looking at the trace in more detail, I found out I have 25312 failed attempts at opening icons located in $HOME/.local/share/icons/hicolor
I do have the hicolor-icon-theme package installed, but apparently the app is not trying very hard get its icons for /usr/share/icons/hicolor:
...
access("/home/tom/.local/share/icons/hicolor/icon-theme.cache", F_OK) = -1 ENOENT (Aucun fichier ou dossier de ce nom)
access("/usr/share/icons/hicolor/icon-theme.cache", F_OK) = 0
access("/usr/share/icons/hicolor/index.theme", F_OK) = 0
access("/home/tom/.local/share/icons/hicolor/128x128/actions/edit-clear-locationbar-rtl.png", F_OK) = -1 ENOENT (Aucun fichier ou dossier de ce nom)
access("/home/tom/.local/share/icons/hicolor/128x128/animations/edit-clear-locationbar-rtl.png", F_OK) = -1 ENOENT (Aucun fichier ou dossier de ce nom)
access("/home/tom/.local/share/icons/hicolor/128x128/apps/edit-clear-locationbar-rtl.png", F_OK) = -1 ENOENT (Aucun fichier ou dossier de ce nom)
access("/home/tom/.local/share/icons/hicolor/128x128/categories/edit-clear-locationbar-rtl.png", F_OK) = -1 ENOENT (Aucun fichier ou dossier de ce nom)
...Who do you think the culprit is here?
Offline
#3 2025-11-23 13:36:26
- seth
- Member
- From: Don't DM me only for attention
- Registered: 2012-09-03
- Posts: 73,680
Re: [solved] extremely slow qt app
Do you have /home/tom/.local/share/icons/hicolor at all?
All paths in $XDG_DATA_DIRS need to be considered XDG_DATA_HOME but it would be weird if every icon was considered in a non-existing path.
I've bemourned the Qt6 QFileSystemModel performance before in some threads and it seemed icon driven, but I'm currently not getting this (but I also don't have icon themes in $HOME and generally almost no icons installed besides hicolor and, sigh, adwaita - no not all that surprising)
Who do you think the culprit is here?
Naive, uncached, encapsulated attempts to find each required icon?
I can hear my laptop struggling
Spinning HDD?
Offline
#4 2025-11-23 14:08:59
- tgirod
- Member
- Registered: 2018-09-16
- Posts: 13
Re: [solved] extremely slow qt app
@seth thanks for the reply
I do have a folder named $HOME/.local/share/icons/hicolor, but the content is rather sparse - mostly icons related to specific softwares, no icon themes installed here.
as for the XDG paths ...
$ echo $XDG_DATA_DIRS
/usr/local/share:/usr/share
$ echo $XDG_DATA_HOME/
/home/tom/.local/share/... it seems to make sense. XDG_DATA_DIRS points to /usr/share so it should find globally installed icon sets such as hicolor-icon-theme, while XDG_DATA_HOME points correctly at locally installed resources. The trace I've posted earlier confirms that the app is looking at /usr/share/icons/hicolor/icon-theme.cache but then decides to search inside my homedir instead.
I've bemourned the Qt6 QFileSystemModel performance before in some threads and it seemed icon driven, but I'm currently not getting this (but I also don't have icon themes in $HOME and generally almost no icons installed besides hicolor and, sigh, adwaita - no not all that surprising)
That's bad. So if I understand correctly the situation, Qt tries to load the hicolor theme, somehow fails at accessing it from /usr/share, then tries to load the whole set of >25000 icons one file at a time from the homedir, failing at each file. what a mess.
When I said "I hear my laptop struggling", I meant one core goes up to eleven and the fan starts spinning hard.
Offline
#5 2025-11-23 14:24:47
- seth
- Member
- From: Don't DM me only for attention
- Registered: 2012-09-03
- Posts: 73,680
Re: [solved] extremely slow qt app
somehow fails at accessing it from /usr/share, then tries to load the whole set of >25000 icons one file at a time from the homedir
$XDG_DATA_HOME/icons should™ take precedence.
I do have a folder named $HOME/.local/share/icons
What happens if you move that to $HOME/.local/share/no.icons?
Offline
#6 2025-11-23 16:55:17
- tgirod
- Member
- Registered: 2018-09-16
- Posts: 13
Re: [solved] extremely slow qt app
What happens if you move that to $HOME/.local/share/no.icons?
Good catch! The trace is not littered with failed access to .local/share/icons anymore, yay \o/
But the app is still slow as hell, noo <o>
Oh well, I guess I'll have to live with it, I don't have the time to investigate this any further unfortunately.
Offline
#7 2025-11-23 20:07:31
- seth
- Member
- From: Don't DM me only for attention
- Registered: 2012-09-03
- Posts: 73,680
Re: [solved] extremely slow qt app
But the app is still slow as hell, noo <o>
Feared as much, your trace amounts to 0.147s, less than half of that in the access calls - compared to > 12s user time…
Oh well, I guess I'll have to live with it
You can, but you certainly don't *have* to.
Is it only the file dialog?
Is it only picard or also eg. https://aur.archlinux.org/packages/qarma-git ("qarma --file-selection" will pretty much just open a QFileDialog)?
Do you use any fancy QPAs (kde, gnome, gtk, …)?
Or does it end up invoking xdg-desktop-portal?
Is only opening the dialog slow or also changing directories inside etc.?
Offline
#8 2025-11-23 21:42:49
- tgirod
- Member
- Registered: 2018-09-16
- Posts: 13
Re: [solved] extremely slow qt app
Thanks for taking the time to guide me on this. Unfortunately I don't have enough free time to troubleshoot this much further.
You are right to point out that the problem is certainly elsewhere, given the relatively small time passed in syscalls. Maybe it's a xdg-desktop-portal problem, and I shouldn't be running some alternative bleeding edge DE such as niri. too old for that shit 
Offline
#9 2025-12-10 15:33:48
- tgirod
- Member
- Registered: 2018-09-16
- Posts: 13
Re: [solved] extremely slow qt app
Hey, I'm giving it another shot because this is driving me crazy. I'm not sure where to start in order to debug that TBH. So, starting from your earlier questions.
Is it only the file dialog?
Is it only picard or also eg. https://aur.archlinux.org/packages/qarma-git ("qarma --file-selection" will pretty much just open a QFileDialog)?
Do you use any fancy QPAs (kde, gnome, gtk, …)?
Or does it end up invoking xdg-desktop-portal?
Is only opening the dialog slow or also changing directories inside etc.?
To recap the problem: some applications are grinding to a halt for ~10 seconds when I open the file picker dialog. The application is frozen, the dialog box is opened but not painted, the fan starts spinning as one core goes to 100% usage. It looks like this.
So far I have witnessed this only when I open a file picker, and not with any application. I've seen it happen with picard, lightburn and plugdata. I believe those 3 apps are QT based, hence my first hunch about a problem related to QT. However, I have tried running "qarma --file-selection", and everything went fine.
My graphical session is running on wayland with niri (and xwayland-satellite for X11 compatibility). I also tried to install sway and gnome and witnessed the same issue.
Regarding fancy QPAs, I really don't know - all I can say is that I followed the wiki and installed qt5ct / qt6ct because I'm running an environment that is not plasma. Is there anything fancy here?
> systemctl --user show-environment| grep QT
QT_WAYLAND_DISABLE_WINDOWDECORATION=1
QT_QPA_PLATFORM=wayland
QT_QPA_PLATFORMTHEME=qt5ct
QT_AUTO_SCREEN_SCALE_FACTOR=1
QT_ENABLE_HIGHDPI_SCALING=1So, it might be a xdg-desktop-portal problem - maybe my application calls xdg-desktop-portal to open the file picker, which fails miserably, and after a while decides to stop waiting and just do it regularly.
Where should I look to test this hypothesis?
Offline
#10 2025-12-10 18:43:15
- seth
- Member
- From: Don't DM me only for attention
- Registered: 2012-09-03
- Posts: 73,680
Re: [solved] extremely slow qt app
So, it might be a xdg-desktop-portal problem - maybe my application calls xdg-desktop-portal to open the file picker, which fails miserably, and after a while decides to stop waiting and just do it regularly.
Where should I look to test this hypothesis?
sudo journalctl -bEdit: look for portal, but don't just grep isolated lines, the context might matter.
picard and lightburn are Qt5 (qarma is Qt6) but plugdata doesn't look Qt at all.
QT_QPA_PLATFORM=xcb picardresp. test this on some X11 session (eg. i3wm or openbox)
Last edited by seth (2025-12-10 18:43:53)
Offline
#11 2025-12-11 12:31:43
- Potomac
- Member
- Registered: 2011-12-25
- Posts: 551
Re: [solved] extremely slow qt app
Do you have also performance problems when you use another Qt6 software ?
I notice problems when I use Kate (a text editor from KDE), since a recent update of Qt6 and Plasma desktop the application becomes slow when I try to open a file, dialogue box open file takes long time to appear, and sometimes the application freezes for one second.
Downgrade to previous version of Plasma (6.5.3) and Qt6 may fix the problem.
Last edited by Potomac (2025-12-11 12:36:13)
Offline
#12 2025-12-17 13:49:39
- tgirod
- Member
- Registered: 2018-09-16
- Posts: 13
Re: [solved] extremely slow qt app
ok, I'm back at it, with a good intuition. I've created a brand new user, logged into the account with a blank $HOME/.config appart from a basic sway config file, and everything is running fine.
So there is something wrong with my user config. I'm going to reintegrate the various parts progressively to pinpoint the problem.
Offline
#13 2025-12-17 14:16:30
- tgirod
- Member
- Registered: 2018-09-16
- Posts: 13
Re: [solved] extremely slow qt app
well, finally, after clearing up everything in .config and putting only what seemed absolutely necessary, everything is back to normal. What can I say ? Thanks for putting up with me !
Offline
#14 2025-12-17 14:21:10
- seth
- Member
- From: Don't DM me only for attention
- Registered: 2012-09-03
- Posts: 73,680
Re: [solved] extremely slow qt app
Did you manage to also pin the culprit?
Offline
#15 2025-12-17 14:48:58
- tgirod
- Member
- Registered: 2018-09-16
- Posts: 13
Re: [solved] extremely slow qt app
Unfortunately I did not pin the culprit.
But I can at least say that I removed .config/xdg-dekstop-* folders, folders related to QT, and also some pipewire media session config (there's a link between pipewire and desktop-portals IIRC ?). I'll check with my backup drive so I can at least diff the folders.
Last edited by tgirod (2025-12-17 14:49:20)
Offline
#16 2025-12-19 19:52:21
- luthis
- Member
- Registered: 2016-02-12
- Posts: 38
Re: [solved] extremely slow qt app
I may be having a related issue (https://bbs.archlinux.org/viewtopic.php?pid=2278672).
If you could post the diff, that would be great thanks!
Offline