Opened 15 years ago
Closed 15 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 by , 15 years ago
comment:2 by , 15 years ago
| 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.