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.
All I wanted was to record a forty-second voiceover for a throw-away video, so I fired up the Windows Voice Recorder app and hit the record button. Nothing seemed to happen.
And then, when I checked later it was recording. I experimented a bit and found that the first time that I started a recording after launching Voice Recorder there was often a long delay before it would respond. A twenty-second delay for recording a forty-second clip is a pretty bad efficiency ratio. This bothered me enough that I wanted some understanding of “why” so I grabbed an ETW trace.
Modern software loves to use additional processes so I wasn’t surprised when the busiest process wasn’t SoundRec.exe, but the verbosely named “RuntimeBroker.exe <Microsoft.WindowsSoundRecorder>”. Looking at its CPU usage I noticed that it got busy as soon as I launched Voice Recorder – before I even clicked the record button.
RuntimeBroker was CPU bound and was spending most of its time in a single thread that was busy performing queries on the results of a crawl over some directory:
The next step was to look at the File I/O graph to see what directory was being scanned. The results were a bit inconsistent (sometimes the scan seemed to stop early?) but it appears that RuntimeBroker was – on the same thread – scanning part or all of my documents directory.
Meanwhile another RuntimeBroker thread was spending a bit of time in propsys.dll!TryGetFileTypeAssocFromStateRepository.
So, I’m guessing that the whole purpose of this was to find all audio files in my documents directory in order to populate the list of previous recordings. And, once I started watching for that I found that when I launched Voice Recorder it would – after a significant delay – fill in a list of recordings. If I clicked the record button after the list was populated then recording would start instantly.
<sarcasm>Clearly this was a case of user error. If I had waited patiently for my slow computer to be ready then it would have been fast and responsive when I wanted to start recording.</sarcasm>
The crazy thing about this delay from scanning my documents directory is that Voice Recorder seems to ignore any audio files that aren’t in the Sound Recordings directory. All that scanning, for nothing?
Complaints and concerns
I have some thoughts about this whole thing…
- The “dir /s” command can scan my documents directory in less than two seconds. Why does RuntimeBroker take 5-10 times as long to do its scan? I only have ~44,000 files in the directory so what filtering could it be doing that adds an extra half-million clock cycles per file?
- Why does RuntimeBroker scan my entire documents directory when Voice Recorder ignores audio files that aren’t in the “Sound recordings” subfolder? Is that a WinRT flaw, or a Voice Recorder flaw?
- What happens with users who don’t have an SSD and 32 GB of RAM? In my case the directory structure of my documents directory was entirely cached in memory so there was zero disk activity required to do the scan, but some users are not so lucky. If those users have more files and a spinning disk then god have mercy on their souls.
- When doing an operation that blocks the user from using the application then a progress meter or busy cursor would be more honest. The Voice Recorder UI was always responsive, but that was a lie – the record button should have been disabled until it was ready.
- Why does the scan of the documents directory sometimes not traverse the entire directory? Is there some RuntimeBroker caching?
I don’t know enough about WinRT and RuntimeBroker to comment intelligently about where the design flaws lie, but I’m confident in saying that a voice recorder app that can’t instantly record voice, on modern hardware, means that there are design flaws.
All of this testing was done on Windows 10, 21H2. On Windows 11 the Voice Recorder app has been deleted and replaced by Windows Sound Recorder, which is a complete rewrite. It looks like the rewritten version has avoided the bug so “yay”, progress, but I fear for the software world when apps are rewritten rather than being fixed.
Hacker news (mostly about slow software in general) discussion is here
Twitter discussion is here and here (second one has the most technical details)
Reddit discussion is here
Random ASCII - tech blog of Bruce Dawson 
Never used it, so I wanted to try. I launched it and saw this:
…
Waited some more…
After about three minutes, it’s ready to scan my documents folder. Not a great ratio. But what the hell, what’s the urgency to force me to update? Is there a zero-click RCE in the current version? Is the recording algorithm too old for Sep 2022? A recorder from Windows 95 could do the job for me!
And, if this update was so important, why wasn’t it automatically applied as part of Windows or Store updates? That seems very mysterious
This is because by default most inbox apps are not installed anymore on the latest Windows 10/11 and are only installed on demand the first time they are launched by the users. This was done to make the install ISO of Windows smaller. So the reason you have to “update” is because the app is not installed yet.
In this case, it shouldn’t lie to me, it should say that the app is not installed. And it would be nice for it to ask me about installing it instead of doing it automatically, but perhaps I’m asking for too much.
I’m pretty sure the product teams discussions around this went along the following lines:
– We already make it look like the program is installed, asking the user if they want to install a program they have already clicked to open would be confusing.
– Because we make it look like the program is installed telling the user that we are installing is more confusing, the average user is used to updates being applied, lets go with that wording. (Personally I think it should say “Setting up for first time use” rather than installing updates, but meh.)
And yet Win95 was what, 120MB and its sndrec32.exe is much better, even allows you to add effects and do minor editing of your recording.
Every time I had to use the Vista based recorder (and 7, 8) I had to Google the undocumented command line parameter just to record a .wav.
The motto “performance no longer matters” has been floating around for a couple of decades now. Somehow despite computers getting literally 1000× faster during that time, it still matters. But it seems every so often some programmer swallows it hook and sinker, and then you end up with a text-based chat application that can no longer keep up with anyone with basic 10 finger typing ability.
https://github.com/mattermost/mattermost-server/issues/15012
(and that is a plain text entry field, not even formatted text. Microsoft Word did formatted and typeset text interactively 30 years ago!)
I remember reading a comment (long time ago so sorry can’t remember who or where) attributed to MS when Windows NT came out and they were asked why it was so slow. The response stuck in my mind. Basically it was we don’t care about performance because the hardware will always catch up. In other words, we’re not interested in spending the time or money to make our software responsive so we’ll let other’s deal with the issue. The other comment I remember from then was along the lines of user’s are smart enough to understand the errors that can occur so our software will just display a general “Error has occurred” message without explanation. Those two things stuck in my mind because to me they perfectly defined the software that MS produced then, and I suspect, now.
I am skeptical about that comment. I have seen the processes they use to detect performance regressions (in the field and before they ship) so I believe that they genuinely care about performance. I also believe that they are ruthless about triage. So, either they never noticed this regression, or they noticed it and decided that Voice Recorder was not used enough to justify the time/risk of fixing it.
I would say that it should never have been written to be that slow – then you don’t need to fix it.
The Microsoft statement I remember reading at that time (~NT4?) was a comparison to UI speed in NT vs 95. The statement was basically that win95 jumped through a lot of complexity hoops in order to appear more responsive, while actually being slightly slower. IE: start menu pops up but you can’t click anything for a moment anyway. And that NT chose to do things the more direct way because machines would get faster and people using NT valued the stability of a less complex system over artificial responsiveness.
What kind of an idiot uses Windows as a daily driver?
People with jobs.
Yes, people with really bad, low paid jobs, who also happen to be computer-illiterate.
Yes, Google software developers such as me on Windows are famously poorly underpaid. Remind me to link to my Patreon so that my readers can support my blog by buying me a cup of coffee
LMAO
Someone who develops Chrome on Windows I imagine
Linux users stop being insufferable challenge
Difficulty level: Impossible
2023 will be the year of Linux desktop
Microsoft!
They just changed the docs in their knowledge base url to learn. technet –>docx –>learn. What else can you say:)
Interesting. So you’re saying one of the causes that modern software is slow is because of unnecessary processes within?
No, I’m not saying that. Extra processes add complexity, but they do not in themselves add _much_ extra cost. They should be used when they add value. In Chrome’s case the extra value is a huge increase in security and stability, for example
Don’t think so. The problem in this application is that it:
1) Refuses to do it’s primary function until a potentially extremely large background task is complete. This is the fundamental design flaw from which all others spring.
2) Uses some method of doing that task that is a few orders of magnitude slower than need be.
3) Searches a much larger region of the filesystem than it will ever use, thus making all the above worse.
And the kicker is of course that users don’t care about the list of recordings in the first place. It’s a recorder, not a player.
Good summary. No notes.
A couple years ago, I was working on a UWP app which needed to list all files in a directory. We initially did it with some WinRT API (I think it was StorageFolder.GetItemsAsync but I’m not sure) and noticed it could take several seconds to list even moderately populated folders and it could take 30+ seconds on more uncommon but still realistic cases.
Thankfully, the good ol’ Win32 FindFirstFileW/FindNextFileW functions are available to UWP apps. We switched to them and they were blazing fast in comparison.
I never investigated why the difference was so drastic though.
Interesting – I really should investigate this. Better yet – somebody else should write some sample code and then I’ll investigate.
Scanning filesystems that can be of any arbitrary size is nearly always going to be a bad idea.
I have worked with Java applications where the framework at startup scans every class in the classpath for annotations in order to implement the brilliant “come from” command, previously seen only in the language Intercal. It can take ten minutes for a business service to become active because it has to access hundreds of thousands of classes to find the ten it needs, which were known to the developer at build time.
Hey, bruce thanks for such a quality update. why modern software is slow. you have researched on valid point and thanks for educating us all.
What is profier that you use?
I use ETW (Event Tracing for Windows) which is a profiling system and visualizer created by Microsoft. I use UIforETW to control the recording and investigation of these traces. For more details see https://tinyurl.com/etwcentral
Nice
Thanks for this! Did you ever find a Windows Voice Recorder app that doesn’t take so long to start up?
The Windows 11 one starts up faster, and since I rarely need the voice recorder I haven’t bothered looking for another one for Windows 10. Now that I know what is going on I can just wait for it to be ready.