Run disk operations in a separate thread (or threads)

[avogelba]

Originally reported by: James Norris (Bitbucket: halfspin, GitHub: halfspin)

---

Running all disk operations (i.e. listing directories and getting file info) in a separate thread or thread pool would substantially improve the responsiveness of the user interface as well as potentially speed up operations on physical hard drives by keeping multiple outstanding requests queued.

Unfortunately it looks like it would require a substantial rearchitecting of the code base to allow multithreaded operation. Right now everything is done in the GUI thread, with the disk operations performed during idle time but limited to a certain maximum delay. Visual updates events are handled periodically during that time but not user interactions.

Separating out the file-reading operations into separate classes with a thread-safe interface between those and the GUI might also help with supporting alternative data sources like SQLite databases or ls -R dumps.

A much easier change would be to check frequently whether any window events are pending and, if so, exit out of the work loop. I might try testing that approach myself.

---

• Bitbucket: https://bitbucket.org/windirstat/windirstat/issue/149

[avogelba]

Original comment by James Norris (Bitbucket: halfspin, GitHub: halfspin):

---

BTW, I identified the SetDone() bug when I reduced the work ticks from 600 to 100 in an attempt to improve responsiveness. The program stopped at the top level of the drive because it ran out of ticks and exited the DoSomeWork() function between the call to SetDone() and the call to UpwardSetUndone().

[avogelba]

Original comment by gen btc (Bitbucket: genBTC, GitHub: genBTC):

---

I think the guy who forked/made altWinDirStat was working on this, (making directory enumeration asynchronous and decoupling it from the graphical tree list view element). And performance in general. But idk how that project is going.