GtkFileChooserDialog takes unreasonably long with large amount of mounts
Steps to reproduce
- Create around a thousand mounts, preferably in a controlled manner such that they can be unmounted later
- Open a file selection dialog in any app that uses GTK
- Observe everything taking forever
Current behavior
The file chooser dialog handles the list of mount points extremely inefficiently, leading to all GTK operations being painfully slow, while waiting for it to finish I captured several backtraces, most of which involve waiting for widgets to resize.
I first encountered this issue with 34000 mounts. After waiting for 2.5 hours for the file dialog to open and render, and closing it at the first possible moment, I captured a backtrace >25000 stack frames deep into gtk_widget_queue_resize_internal
calling itself, implying each mount in the list is a child of the previous mount.
Expected outcome
The file chooser should remain interactive even with thousands of mounts. The list of mounts should not contain thousands of nested size groups (or whatever is actually happening under the hood).
Other file management programs, like Thunar remain fully responsive even with >34000 mounts listed.
Version information
- libgtk 3.24.24
- NixOS 21.05pre278406.d3f7e969b98 (Okapi), with Linux 5.4.64
Additional information
Most of the mounts involved with this issue are duplicates due to a bug in a chroot script causing the amount of mounts to grow exponentially each time the chroot script runs due to bad use of mount --rbind
. While removing duplicate mounts would help with this issue, it would not fix the root cause of the performance problem.