3 ms·

Someone has not told Microsoft | It is not as simple as that. On some Windows machines with network-mounted drives, the File-Print-to-pdf dialog takes *minutes

Someone has not told Microsoft | It is not as simple as that. On some Windows machines with network-mounted drives, the File-Print-to-pdf dialog takes *minutes* to become responsive, even when all currently open files are on a local drive. This is the kind of thing the author is talking about. The programmers of that dialog box probably just called a generic "open file dialog" library function, without researching its worst-case performance. In turn the library writers probably blithely coded something like "check if all mounted drives are accessible", without stopping to consider the worst-case performance.

pdonis 3y ago
> Someone has not told Microsoft More like the part of Microsoft that implemented non-blocking I/O for Windows some time ago never bothered to tell the part of Microsoft that writes the generic Windows UI code for things like the open file dialog. Or for Microsoft Office applications, for that matter; I still see Word and Excel block the UI thread when opening a file from a network drive, even though Windows has perfectly good asynchronous file I/O API calls.
- kudokatz 3y ago
  > never bothered to tell the part of Microsoft that writes the generic Windows UI code no, they just don't care.
pradn 3y ago
The file picker on Windows should be thought of as more like a process than a function call. It has to 1) read the metadata of the current directory’s files 2) look up which icon to use for each 3) load the icon 3) call apps that may modify the file icon overlay (like “synced” or “not synced” cloud icons for Cloud file systems like Google Drive) 4) read the registry for various settings 5) load which pinned files a user set up - etc etc. All this involves dozens of disk reads, calling into third party code, etc. A lot of this may be cached but who knows. The alternative to this is to roll a barebones file picker - there might even be one available in the Windows API.
- rootw0rm 3y ago
  You're right, Sysinternals Process Monitor will show lots of stuff going on for your example.

pdonis 3y ago

> Someone has not told Microsoft More like the part of Microsoft that implemented non-blocking I/O for Windows some time ago never bothered to tell the part of Microsoft that writes the generic Windows UI code for things like the open file dialog. Or for Microsoft Office applications, for that matter; I still see Word and Excel block the UI thread when opening a file from a network drive, even though Windows has perfectly good asynchronous file I/O API calls.

kudokatz 3y ago
> never bothered to tell the part of Microsoft that writes the generic Windows UI code no, they just don't care.

pradn 3y ago

The file picker on Windows should be thought of as more like a process than a function call. It has to 1) read the metadata of the current directory’s files 2) look up which icon to use for each 3) load the icon 3) call apps that may modify the file icon overlay (like “synced” or “not synced” cloud icons for Cloud file systems like Google Drive) 4) read the registry for various settings 5) load which pinned files a user set up - etc etc. All this involves dozens of disk reads, calling into third party code, etc. A lot of this may be cached but who knows. The alternative to this is to roll a barebones file picker - there might even be one available in the Windows API.

rootw0rm 3y ago
You're right, Sysinternals Process Monitor will show lots of stuff going on for your example.