How to hopefully speed up voiceover launch time and performance on Mac, no terminal required!

By Levi Gobin, 4 May, 2023

Forum

macOS and Mac Apps

That’s right, I finally figured out how to give voiceover priority access to the CPU!
I did some digging to find out how to do this. I copied a command from a website that said it would give an app priority access to the CPU. The website suggested that your application was in /applications, but that’s not where voiceover is stored. It is stored in /system/library/coreservices/VoiceOver.app. You don’t even have to copy or paste any terminal commands, because I was nice enough to compile it in a nice little Automator app.
All I do is any time I am on a new system, I run the app. If I feel like it’s been changed, I go to my utilities folder and run the app again.

Basic overview of the app

This app runs a few basic shell scripts. It takes less than two seconds to run on an M1 MacBook Pro.
The first shell script runs the command which gives voiceover priority access.
The second shell script kills voiceover. The next shell script opens voiceover.app and the voiceover starter UNIX executable file located in the contents of VoiceOver‘s app. If I do not run that, voiceover hangs and then requires you to restart voiceover manually, so let’s not do that... As a downside to opening units executable files, unneeded terminal windows will open. I also have another shell script which will announce that voiceover is restarting, and close that terminal window and bring you back to your previous working window.
It is that simple! it is really easy to use. Simply open the app in your downloads folder, and Bam! Voiceover will have primary access to your CPU.
I do not know if the setting is changed after a computer restart, so if voiceover starts misbehaving after you restart, go ahead and give that app another command+o. Here is a dropbox link to download the file.
https://www.dropbox.com/s/e0gnemjsqbpjdgu/priority%20voiceover.app.zip?dl=1
If it is in a zip file in your downloads folder, navigate to the zip file and press command O to open the zip file and extract the app. If it is not a zip file or if you have already extracted the zip file, press command o on priority voiceover.app.
If you are warned about this app is not verified, etc., press Ctrl option shift M on the app to open the context menu and select open. You will get an alert asking you if you are sure you wish to Run the app and that the Developer cannot be verified by macOS. since this app was made with Automator and I’m not Microsoft or any other big major company with a verified developer certificate. Go ahead and say yes, and just like that, voiceover will have priority access to your CPU. In the future you will not have to tell macOS you want to run the app. It will just run next time.
If you have macOS’s built in gatekeeper disabled, you will not have to worry about that.

Options

Comments

THANK YOU SO MUCH FOR THIS…

THANK YOU SO MUCH FOR THIS. HOPEFULLY THIS WILL MAKE THIS POOR INTEL MACBOOK PRO WITH 2.4 GHz Quad-Core Intel Core i5 WORTH USING. I CAN'T BELIEVE APPLE WOULD MAKE A MAC THIS LOW SPECED, AND THAT VOCATIONAL REHAB WOULD BUY IT, BUT IT'S WHAT I HAVE.

Thank you for sharing

Thank you for sharing this helpful tip and tool for making the suggested change. Before proceeding with the change, I would appreciate hearing about any improvements you have noticed on your own machine. It would also be beneficial to know which Mac models and versions of macOS you have tested this on, and if the results have been consistent across different machines.

In case someone encounters issues with this change, could you please provide instructions on how to revert it back to the original settings? This would be helpful for those who may need to undo the change if it doesn't work well for their specific setup.

the app is damaged

It says that the app is damaged.

Download it with wget or…

Download it with wget or something.

Njet

What’s that?

It's a terminal program,…

It's a terminal program, just wget and paste the link.

Ok

I may try it on my mba m1

The app isn’t damaged.

it’s not damaged, but macOS thinks it is.
To fix this issue, open Automator in your applications folder. Then in the open dialogue, find the priority voiceover app you downloaded. Once in the Automator app, press command shift S for save as and save it to a new location. Then run the app from the new location, and that should be good.
As far as resetting it to the defaults, I am not sure on how to do that yet but I am actively looking for a solution.
I have tried this on my M1 MacBook Pro running Mac OS 13.3.1. That is the only system I have tried this on.
Please feel free to share your feedback as well as any other comments you may have.
As far as any improvements, I noticed that voiceover was way quicker to open, i.e., a second and a half before, a quarter of a second after. I may be exaggerating, but it was that noticeable. Voiceover seems to perform better, with less lag and slow downs.

This does seem to have made…

This does seem to have made the long wait to restart voiceover vanish. Nice work. Now, to check out safari... Wish me luck.

More details, please?

Would you mind publishing what Terminal commands you used in this app? Is it just the Nice command or there is more? Also, what advantages do you think one gains by giving VoiceOver a higher priority? On a powerful Mac machinethis should really make no difference.
Thank you! .

Terminal commands

All I used was the nice command.
The article I found on how to do this can be found here: https://www.techrepublic.com/article/how-to-adjust-cpu-priority-using-apples-terminal/
The exact terminal command i used to get voiceover high priority was
sudo nice -1 "/system/library/coreservices/voiceover.app/macOS/voiceover".
Then I used the killall command to kill voice over, then a few other terminal commands to start up voiceover. The exact command to kill voiceover is,
killall VoiceOver
If you have any other questions or comments, please let me know.

Is this just for improved startup?

Or does it help VoiceOver behave any better in general?

Would be interested to hear from anyone brave enough to try. My Mac has become pretty sluggish recently so I'm a bit nervous about trying. It does take a while for VO to start up, and sadly I need to restart several times a day, but there are other bigger problems.

Improved performance

This also improves the speed of voiceover launch times, and general improvements to voiceover stability. Voiceover runs a lot faster for me.

Experiences?

Hello everyone,

For those of you who've now had some time since making this change, I would love to hear your feedback on any improvements you have noticed in VoiceOver's performance. Have you experienced fewer instances of the 'not responding' issue? Have you noticed any changes in responsiveness when using specific apps or navigating web pages? Or have you encountered any regressions or issues that you think may have been introduced by making this change? Your insights would be greatly appreciated.

I appreciate any feedback!

Yes, I think some clarity is in order

I haven't downloaded or tried your workflow, but from the description I would hazard a fairly good guess that your understanding is a little bit off, so let me explain, and proffer an alternative, much simpler option (that requires Terminal).

Processes on UNIX have a "priority" which, as you noted, decides the relative favour (CPU time) that they receive, when compared to other processes. (We will ignore details about scheduling classes on systems that have them, because that would just make everything more complicated.) The nice command spawns a process with the scheduling class you give; -1 would mean slightly less nice (more favourable) than the default of 0. If a typical unprivileged user process (such as VoiceOver) desired, it could change its priority, but only by being nicer (increasing), to a maximum value of 20. The system administrator (that's you) can also change the priority of a process to be either nicer (positive number, max 20) or less nice (negative number, minimum -20), using the renice command, by escalating to root (that's also you) using the sudo command. At no point does the priority of a process somehow become saved or persist in any way, by either of these methods; you must arrange to spawn (or renice) a process every time it starts or restarts.

So, now, your scripts. It is not useful to spawn another copy of VoiceOver, then immediately kill (terminate) all of the copies of VoiceOver, including the one you just started. I would be surprised if it actually worked; you just stumbled on the fact that when you start it a second time, this time with the correct priority, it now appears to be changed. So, instead, simply "renice" the process you already have. Here's a one-line terminal command that will renice any process with "voiceover" anywhere in the title (name and arguments, case-insensitive search):

    sudo renice -20 `pgrep -afil voiceover|cut -d ' ' -f1`

Copy and paste that command into Terminal, press Enter, then type in your password (assuming you are logged in as the administrator, of course). I just tried it, and so far I haven't really felt anything. But the whole web beckons with opportunities to test it out, with "not responding" messages pretty clearly indicating no real change in the usual deadlock conditions.

I will say, though, that this is not without risk; if VoiceOver should "run away" (go mad and start consuming CPU because of a bug) then it might be that it actually increases lockup and instability potential, rather than decreasing it. The idea is certainly intriguing, but I think you should get it right and test it thoroughly before endorsing it as a cure.

I hope you will understand that, though I hope it works, I'm not prepared to put my faith in such a simple fix until I can demonstrate that it really makes a meaningful difference. Knock on wood, no problems yet. It seems to me that there are more inter-related components that would be involved in providing accessibility services than just VoiceOver, however. Which subsystems implement the accessibility protocols that VoiceOver uses? Will they have any other impact? Otherwise this could all be a very red herring.