Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads
Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads
- Subject: Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads
- From: Allan Odgaard via Cocoa-dev <email@hidden>
- Date: Thu, 23 Apr 2020 12:16:50 +0700
On 20 Apr 2020, at 0:11, Allan Odgaard via Cocoa-dev wrote:
Unfortunately though I can’t figure out *what* the problem is;
running `tccutil reset All` (and rebooting) did not fix it.
It appears the problem is not with a local service, but that Apple
actually “phones home” when a program asks for display name.
I don’t know if this is common knowledge, but with notarization, Apple
now validates executables on your system before they are executed, and
it does so in calls like execve(), where it will actually stall
execution, contact Apple’s servers, and then proceed once the
executable got validated.
I *thought* this was the only place it did it, and that the result got
cached (based on inode).
But it seems Apple added this to other places, because since I have
upgraded to macOS 10.15, I see *many* delays.
This is because I am currently in South East Asia where the connection
to Apple’s servers is not good.
For example I have a script that takes a video file as argument, it
launches VLC with this video file, and then deletes the file when VLC
terminates.
It can take more than 5 seconds just until VLC is launched, and then VLC
will be “thinking” for another 5 seconds, before the video actually
starts.
Today the delays were extra bad, so it was easy to reproduce the VLC
issue, obtaining display name (which today took 7 seconds for 3 names),
and a few other things.
Now, if I disable internet, no delays at all!!!
Enable it again, and all the delays are back.
It is so utterly frustrating that Apple is not only going down this path
of locking down our machines, but they do it in ways that are so
crippling for our productivity :(
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden