I wonder if running Sound Recorder, within a virtualised Windows 3.1 environment would be quicker than the time it takes for Windows 11 Voice Recorder to be ready?
Almost certainly. I ran Windows 3.11 on a 166MHz Pentium and it was insanely fast. It launched instantly, everything else was instant. Icons were tiny on a 1024x768 monitor. QEMU in emulation mode (not virtualised) is faster than that computer on a modern CPU.
I’ve had two particularly bad experiences with file browsers: a few years ago, opening either open or save dialog on gimp or firefox would pause everything for several seconds every time, and if the cache was cold, even longer. I had about 4,000 files in my home directory (this linux) and a spinning drive at the time. This was extremely painful, especially because I almost always knew the filename I wanted and if it’d just let me type, I’d be done! Even hitting tab a couple times in bash would be a bit slow (not as slow as the gtk applications but still a bit slow) as it pulled the list, but at least I can choose not to hit tab there and type the filename.
Future versions of those same applications changed that load to be async. This brought some improvement - I could actually type a filename while it loaded, and get on with work - but it also brought its own problems. One notable problem is if I did try to select a file with the gui, it’d have the issue of randomly changing out from under me! That is, I type a couple letters, it loads a file and I see the one I want, so I’d hit down then enter, or grab the mouse and click on it… but in the time between me selecting and clicking, the item would change and I’d then accidentally load the wrong file! (and the gtk file dialog loads things in a really weird way, recursive through subdirectories but filtering on filename alone, no directory name, which exacerbates the confusion here, doing more work and jumping around more so totally not helping, but even if it didn’t do that, async load order is not necessarily sorted the same as you’d see in the ui so if you try to sort it alphabetically for display you are still liable to have things jump around)
What I did in my gui framework in response to all this is my file dialog doesn’t load anything unless you hit browse or tab completed, then it will atomically update the ui when it is done. Some of my users hated this though since they’re so used to something auto populating… ugh.
Still I think there are a couple general lessons from this and the OP link: doing work that doesn’t have to be done can slow things down, and making that async doesn’t necessarily improve things. You need to async in such a way that the user can still do work (so the voice recorder failed at that since the button didn’t actually function) and in such a way that the ui isn’t randomly changing as things load. And, of course, any async job needs to be cancellable if it ends up being totally unnecessary, which I also see applications fail at (and libraries too - that’s now the main place i look to see if an async api has much experience: how does it cancel?). There’s a lot more to doing it well than it seems at first glance… and I think there’s still a lot to say for just waiting for the user to tell you what they want.
Answer: Because some project manager had a requirement that it should show recently created sound clips, some programmer didn’t have time or energy or wisdom to implement it right, and nobody tested it thoroughly or dogfood’ed it so stupid edge cases were missed.
It really bothers me when people blame programmers or certain technologies instead of the conditions they operate under for the vast majority of cases.
I’d ask: is storing documents recommended by the OS in this way or not? Are there guidance or widely known best practices to avoid this scenario? Or every single program in the Windows environment defaults to “Documents”?
Given his track record of identifying performance problems in Windows apps, and not just minor ones. which mostly boil down to “the app is doing way to much, often unnecessary, work”, I think he is entitled to use this title.
That may well be, but this specific article in isolation (which is what most of us are judging by) does not substantiate the claim. The author even acknowledges it in the first paragraph:
I apologize for this title because there are many things that can make modern software slow. Blindly applying one explanation without a bit of investigation is the software equivalent of a cargo cult. That said, this post describes one example of why modern software can be painfully slow.
I don’t understand the apology and think the title is fine. I read it like: “Why criminals are caught (part 38) – (the case of) the Hound of Baskervilles”. Where the parenthetical parts are optional. You wouldn’t think a blog post with that title would claim all criminals are caught because of the specific reason in that case.
I remember the Windows 3.1 Sound Recorder being fast and responsive on my 386SX-16.
I wonder if running Sound Recorder, within a virtualised Windows 3.1 environment would be quicker than the time it takes for Windows 11 Voice Recorder to be ready?
Almost certainly. I ran Windows 3.11 on a 166MHz Pentium and it was insanely fast. It launched instantly, everything else was instant. Icons were tiny on a 1024x768 monitor. QEMU in emulation mode (not virtualised) is faster than that computer on a modern CPU.
I’ve had two particularly bad experiences with file browsers: a few years ago, opening either open or save dialog on gimp or firefox would pause everything for several seconds every time, and if the cache was cold, even longer. I had about 4,000 files in my home directory (this linux) and a spinning drive at the time. This was extremely painful, especially because I almost always knew the filename I wanted and if it’d just let me type, I’d be done! Even hitting tab a couple times in bash would be a bit slow (not as slow as the gtk applications but still a bit slow) as it pulled the list, but at least I can choose not to hit tab there and type the filename.
Future versions of those same applications changed that load to be async. This brought some improvement - I could actually type a filename while it loaded, and get on with work - but it also brought its own problems. One notable problem is if I did try to select a file with the gui, it’d have the issue of randomly changing out from under me! That is, I type a couple letters, it loads a file and I see the one I want, so I’d hit down then enter, or grab the mouse and click on it… but in the time between me selecting and clicking, the item would change and I’d then accidentally load the wrong file! (and the gtk file dialog loads things in a really weird way, recursive through subdirectories but filtering on filename alone, no directory name, which exacerbates the confusion here, doing more work and jumping around more so totally not helping, but even if it didn’t do that, async load order is not necessarily sorted the same as you’d see in the ui so if you try to sort it alphabetically for display you are still liable to have things jump around)
What I did in my gui framework in response to all this is my file dialog doesn’t load anything unless you hit browse or tab completed, then it will atomically update the ui when it is done. Some of my users hated this though since they’re so used to something auto populating… ugh.
Still I think there are a couple general lessons from this and the OP link: doing work that doesn’t have to be done can slow things down, and making that async doesn’t necessarily improve things. You need to async in such a way that the user can still do work (so the voice recorder failed at that since the button didn’t actually function) and in such a way that the ui isn’t randomly changing as things load. And, of course, any async job needs to be cancellable if it ends up being totally unnecessary, which I also see applications fail at (and libraries too - that’s now the main place i look to see if an async api has much experience: how does it cancel?). There’s a lot more to doing it well than it seems at first glance… and I think there’s still a lot to say for just waiting for the user to tell you what they want.
Answer: Because some project manager had a requirement that it should show recently created sound clips, some programmer didn’t have time or energy or wisdom to implement it right, and nobody tested it thoroughly or dogfood’ed it so stupid edge cases were missed.
C’mon man, don’t use clickbait titles please.
This
It really bothers me when people blame programmers or certain technologies instead of the conditions they operate under for the vast majority of cases.
I’d ask: is storing documents recommended by the OS in this way or not? Are there guidance or widely known best practices to avoid this scenario? Or every single program in the Windows environment defaults to “Documents”?
Better title: a minor Windows program is a lot slower than it should be, for this user.
Given his track record of identifying performance problems in Windows apps, and not just minor ones. which mostly boil down to “the app is doing way to much, often unnecessary, work”, I think he is entitled to use this title.
That may well be, but this specific article in isolation (which is what most of us are judging by) does not substantiate the claim. The author even acknowledges it in the first paragraph:
I don’t understand the apology and think the title is fine. I read it like: “Why criminals are caught (part 38) – (the case of) the Hound of Baskervilles”. Where the parenthetical parts are optional. You wouldn’t think a blog post with that title would claim all criminals are caught because of the specific reason in that case.
Are there users for whom waiting an extra 20 seconds before they can start using a program is acceptable?
No, but there are likely users with fewer than 40,000 files in their Documents directory.