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?
I have some thoughts about this whole thing…
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