Opened 14 years ago
Closed 14 years ago
#108 closed defect (fixed)
File dialog is very slow if there is a lot of files to display
Reported by: | Dmitry A. Kuminov | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | Qt Beta 5 |
Component: | QtGui | Version: | 4.5.1 Beta 3 |
Severity: | Keywords: | ||
Cc: |
Description
I found that QFileDialog behaves really slow (gives 100% CPU load) if you enter a directory containing 100+ files.
Change History (2)
comment:1 Changed 14 years ago by
comment:2 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Note: See
TracTickets for help on using
tickets.
It turned out that the slowness is due to QPollingFileSystemWatcherEngine (which is used on OS/2 to monitor file system changes in QFileDialog and friends).
The slowness was caused by the fact that if we have more than 100 items to watch, the poller thread can't process them within the polling interval (1 second). As a result, it is constantly doing file stat which consumes 100% of CPU. Additionally, the poller thread had the normal priority (the same as the main GUI thread) which made it virtually impossible to stop it.
For example, after dismissing the mplayer.exe file selection dialog in SMPlayer, the latter was getting completely unresponsive because of that -- all CPU was eaten by the poller.
In r374, I improved QPollingFileSystemWatcherEngine to not eat 100% of CPU (it now consumes around 50% on several hundred of files in the directory) and lowered the thread priority so that the main GUI thread isn't blocked any more.
This isn't perfect anyway; a perfect solution is described in #6.