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.
From my experience that only happens on Windows 11. Windows 10 has always had the inbox apps ready to go, even on 22H2! I guess not including Inbox apps helps reduce the already 5GB ISO file and also forces users to get the latest version, which they really want for some reason. I don’t care about outdated software as long as it works, like there isn’t gonna be a vulnerability issue in my 1 button audio recorder right?
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.
Go to https://store.rg-adguard.net/, set the first dropdown to PackageFamilyName, paste “Microsoft.WindowsSoundRecorder_8wekyb3d8bbwe” in the input field, set the second dropdown to Retail, press the checkmark and look for the oldest version “2017.510…” and download and install. I think this version doesn’t have the bug yet but it could be that it does, I have an even older version in my archive, but I think you can find one when searching for the inbox app iso for older versions of windows too.
Check this out: Windows 10 1607 Inbox Apps. I am 100% sure the recorder app in there works completely fine with no slowdowns even though the design is a bit outdated as it has no acrylic and reveal effects.
Downloading software from random locations on the internet is a great way to get your computer owned by somebody malicious. I don’t recommend this.
however, cross referencing and verifying hashes/certificates of such software no longer makes the files random, especially if the source is well established (unless the source got hijacked, which has happened to major public entities such as ccleaner, so one should always verify every binary every time from any source anyway)
in this case, rg-adguard has established itself over the past decade to merely generate direct microsoft domain store urls, the same thing the store app does in the background without needing the app or without it obfuscating the interface… personally i cant stand the uwp/rt platform and i’d rather not use any such ‘apps’ so i’d disable or rip out the store entirely (it also doesnt exist in LTSC in the first place)
the archive link is questionable, but one could verify those files by grabbing an (again verified) official microsoft iso from the specified dates around 2016, virustotal might also show appropriate first seen dates and microsoft certificates for a particular appx file for a quicker check (they’re even zips so one could individually inspect every file that would get installed to be sure, yes i’m aware of archive formats being exploitable as well so caution when extracting)
in the end you do have a good point as stated in your start menu post, a billion people use windows and with mostly default settings or apps, they shouldnt be required to install third party code (even though i cant stand the defaults, completely replace the start menu, and go to extreme rabbit hole lengths to tweak and disable windows features/processes/services/tasks to make it lean and manageable… the many ridiculous blunders like this make it obvious the userspace side of windows has bad development practices and/or basic apps like these are likely delegated to entry level or web-frontend developers)
At the place I work for we do use one damn expensive program which not only looks for “recently used files” just to display an nice “welcome” message, but due to unknown reason attempts to open them. Probably to get an icon for them maybe? When they do reside on the network storage which is down it needs about ~20 second for each file to timeout. Thous You start it, wait five minutes and it runs…. unless You are smart enough to pull out the net cable to speed up the timeout.
Another example was 0.4x Inkscape which really hard tried to generate file preview, using main gui thread, for every file You touched in “open file” dialog. Thous efficiently freezing for few tens of seconds on each huge file You dared to point Your mouse at.
Next case I know is a GitBlit server which tries to display a commit web page on which it loves to show a percentage of each file change in a form of four or five tiny boxes aside of each file. Once I dropped there 100MB commit with few tens of thousands of files my server literally died due to the fact, that it loved to run a full diff on each of them.
All three cases are rather non important from coder point of view. They are just bells-and-whistles addition to main functionality and probably nobody really cares to test how do they behave under a boundary conditions. You just add them, test if they work and don’t care about users with tens of thousands files dumped in a single folder. We just do the work and don’t put any limits, like for an example, to take care to not spent on such an unimportant task more than few seconds.
Well… I had to add such an limit to my fork of Gitblit tough. I can’t let a server at my workplace to just die when users are using it in what we think, a normal way.
Third, more interesting case was, an old Linux Krusader which, at certain point, was almost freezing on large folders. It could be clearly visible that once a file was added to a files list it was detecting a file list change and was re-building the GUI for a list from the scratch. Possible re-looking for icons again. This is a typical cause with model-view-observer style of programing which lacks event collation and/or a “bulk change” notification and changes N complexity into almost N^N.
Maybe then in Your case You also do observe a side effect of such an approach? If for each of Your 44’000 of files a notification event will be triggered which will have to look through already loaded files to re-build (or just compute a GUI size) of a list, then it can easily kill any machine.
Hey, I was having similar problems but my Documents folder is very large (200k+ files and folders) and I have a mechanical disk. I always found the opening of the recorder app very very slow but never thought anything of it, I just thought it took a lot of dll files or something else that cause it to be a bit slow to open. I wanted to try the app on this computer with the 200 thousand files in my documents folder and the app just wouldn’t start recording, it’d just have the button turn grey after clicking it. I let it sit for an hour. Nothing. I let it sit for 2 hours. Nothing. I checked task manager and it would sometimes do some disk activity and then stop again but the CPU kept going at 50% used by runtime broker. I thought it might have to do with file permissions so I renamed the voice recordings folder in documents and it created a new one upon opening the app, so I thought that must not have been it. I checked resource monitor and it would report runtime broker reading everything in my documents folder one by one. Even better yet, after going through 1/5th of a million documents it moved on to the AppData folder where there’s another 20 thousand or so files including an entire Kali Linux installation. I let it scan through it and it just wouldn’t stop. The memory very very slowly goes up and it seems to never stop. I thought “oh it must be looking for m4a files or wav files” so I hoped it was a one time process, but I think it may be doing this scan every single time I open the app instead of saving the results somewhere in the settings.dat registry or something like that. The weird thing is that this issue is not there in older versions of the recording app! I have an archive of AppxBundle files for these stock apps and you can even still get a couple older versions from https://store.rg-adguard.net/ if you choose the Retail ring, there is I think a version from 2016 that runs absolutely fine without a single second wasted, the app opens and works instantly. I tried versions from 2017, takes ages to open, 2018, takes ages to open, 2021, takes ages to open. It must be a bug or something but I don’t want to be forced to use the 2016 version of the app, it doesn’t have the project Neon design which is the only real reason you’d want to use this recorder, it’s simple and elegant but this runtime broker thing takes like 5 hours to complete which is a dealbreaker. I tried it on a different user with an empty documents folder and the app works instantly! I really hope moving my 200k files to the desktop will resolve the problem. I assume it is actually scanning for files created by voice recorder because I noticed the version from 2016 doesn’t rename the recording folder, no matter your system language it would write the files to Sound Recordings while the versions that scan the entire documents folder write the folder to “Sound Recordings” for english users and “Gebruiksopnamen” for Dutch users and stuff like that. It might also find the source of recordings that were manually moved outside the default recording folder and I noticed the versions that scan have an option to show the recording in Explorer further suggesting that it might as well support finding recordings not present in the default location altho it may also be for convenience. I think this runtime broker thing is an aweful design by whoever implemented it, it kind of ruins the app completely! I searched on google for solutions and found nothing until I did more research and found this site which explains the same hypothesis I had. I hope to find a workaround.