Защо съвременният софтуер е толкова бавен – да погледнем Windows Voice Recorder

Оригиналът е на Bruce Dawson, който има голям брой интересни постове, които разкриват по нещо интересно и обикновено имат много коментари

Извинявам се за това заглавие, понеже съвременният софтуер може да бъде бавен по редица най-различни причини. Сляпото използване на някакво обяснение без да бъде направено необходимото изследване е нещо като софтуерен аналог на карго култа. Тук ще се спра само върху един пример, който показва защо съвременното програмно осигуряване може да бъде мъчително бавно.

Аз имах желанието само да запиша озвучаването на несложен клип с продължителност около 40 секунди. Ето защо стартирах стандартното приложение Voice Recorder на операционната система Windows и кликнах върху бутона за запис. Изглежда нищо не се получи.

По-късно проверих и се оказа, че програмата все пак извършва запис. Направих няколко експеримента и стана явно, че ако натисна бутона за запис веднага след стартирането на програмата, нейната реакция идва след дълго забавяне. Забавяне от 20 секунди за записа на 40 секунди глас е твърде нисък КПД. Това толкова много ме ядоса, че реших да извърша ETW трасиране.

Съвременният софтуер много обича да използва допълнителни процеси и аз изобщо не се учудих, че най-много ресурси използва не SoundRec.exe, а RuntimeBroker.exe <Microsoft.WindowsSoundRecorder>. Когато се вгледах в показанията за използвания процесорен ресурс видях, че натоварването на CPU рязко нараства при стартирането на Voice Recorder, още преди да съм кликнал върху бутона за запис.

Видях, че RuntimeBroker силно натоварва процесора и използва почти всичкия взет от него ресурс за работата на поток, който непрекъснато извършва запитвания към някаква папка.

След това погледнах графиката на файловия вход/изход, за да разбера коя папка се сканира от този процес. Оказа се, че RuntimeBroker сканира част от папката с моите документи, а понякога и цялата папка.

В същото време още един поток на RuntimeBroker изразходваше време в propsys.dll!TryGetFileTypeAssocFromStateRepository.

Предположих, че целта на всичко това е да се намерят всички аудио файлове в моята папка с документи, за да се допълни списъка с имената на предишните записи на гласа с помощта на тази програма. И когато разгледах по-подробно, стана ясно, че при стартирането на Voice Recorder програмата след огромна пауза наистина съставя и допълва списъка с тези аудиозаписи. Да, ако кликна върху бутона за запис след това допълване на списъка, то записът на гласа ми започва мигновено.

<сарказъм> Очевидно е, че в този случай грешката е на потребителя. Ако търпеливо бях изчакал докато моят бавен компютър стане готов, то при началото на записа програмата щеше да бъде бърза и отзивчива. </сарказъм>

Безумието на това ужасно забавяне заради сканирането на папката с документи е в това, е програмата Voice Recorder изглежда игнорира всички аудио файлове, който не се намират в папката на самия Voice Recorder. И какво? Цялото това сканиране за нищо?

Жалби и опасения

По повод всичко това аз имам някои съображения…

1. Командата dir /s сканира цялата папка с моите документи само за две секунди. Защо сканирането на RuntimeBroker отнема от 5 до 10 пъти повече време? В тази папка аз имам около 44 хиляди документа и какво толкова върши и филтрира този процес, че за всеки файл добавя излишни половин милион такта?
2. Защо RuntimeBroker сканира цялата папка с документите след като програмата Voice Recorder игнорира аудио файловете, които не са в нейната подпапка. Това проблем на WinRT ли е или на Voice Recorder?
3. Какво се случва с потребителите, които нямат като мен бърз SSD и 32 GB оперативна памет? В моя случай структурата на папката Моите документи изцяло е кеширана в паметта и при сканирането флаш дискът няма активност, но много потребители не са такива късметлии. Ако някой има повечко файлове и те са записани на хард диск, остава само да го съжалим
4. При първоначалната работа на програмата Voice Recorder би било по-честно бутонът за започване на записа да остава неактивен докато приложението не стане готово. А така потребителят може да го натисне, но записът на гласа започва чак след приключването на това сканиране, като продължителността на самото сканиране всеки път е различна и не може да се каже кога Voice Recorder е готова
5. Защо сканирането понякога се извършва само за част от тази папка? Да не би RuntimeBroker да използва някакво кеширане?

Аз нямам достатъчно познания за WinRT и RuntimeBroker, за да мога ясно и точно да обясня, какви са причините за тези проблеми, но уверено мога да кажа, че ако едно обикновено приложение-диктофон не може да започне мигновено да записва моя глас при използването на най-съвременен хардуер и софтуер, то в цялата архитектура и система определено има сериозни недостатъци.

Всички тестове направих с операционната система Windows 10 21H2. Интересно е, че в ОС Windows 11 приложението Voice Recorder е заменено с Windows Sound Recorder, кодът на което е изцяло преписан. В преписаната версия този бъг не се проявява, но аз се притеснявам за света на софтуера, в който приложенията не се оправят, а се преписват отначало.