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…

1. 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?
2. 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?
3. 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.
4. 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.
5. 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