- In System Preferences uncheck `General > Close windows when quitting an app
- Open TextEdit.app
- Press Cmd+N for a New file
- Quit TextEdit.app
- In Finder go to
~/Library/Containers/com.apple.TextEdit/Data/Library/Saved Application State/com.apple.TextEdit.savedState/
we'll be looking for a file here shortly - Open TextEdit.app
- Quickly, open the file
restorecount.plist
that has appeared in Finder - Look at the
end
value
Currently, on my macOS installation, end
has a value of 570214618 which, as I understand it, means that since whatever epoch — a long time ago in an operating system far, far away — there have been over 570 million "windows" opened on my Mac. The value is shared across all user accounts. 10 months ago, that number was 544 million on my system according to this old question of mine: https://apple.stackexchange.com/a/320967/15281
The effect of this is that, for some apps, there is a noticeable (4 to 5 seconds) delay whilst they do something before their restored windows appear. My workaround, see the above linked question, is to turn off window saving for those specific apps. But I'd rather not have to do that.
So, I'd like to reset the restorecount
value at its source. Does anybody know where it is stored and/or how can I reset it?
Best Answer
The
end
value is not the number of windows you have opened, it is a Cocoa timestamp.570214618
corresponds toJanuary 26, 2019 4:56:58 PM GMT
. As far as I can tell, the purpose ofrestorecount.plist
is just to track how long it takes to restore the windows.For apps that are taking a long time to start, you can try cleaning out their saved application state and see if that helps, but there are lots of other reasons an app might take a long time to start. The most common reason an app takes a long time to start is that it needs a lot of memory and you are already using all the available RAM so some memory needs to be compressed or written to disk in order to free up memory for the app. You can get a sense of this by looking at the "memory pressure" in the Activity Monitor.
You can also look at the amount of Swap Used (also in Activity Monitor). If that number goes up when you launch an app, then not having enough free memory is definitely a source of delay.