The PlayerPrefs class is a platform-independant way of saving data in Unity3D. A bit more than three years ago, we wrote our own implementation of this class, as we weren’t very happy with the speed of the native implementation, especially on mobile. This implementation, called PreviewLabs.PlayerPrefs, can be downloaded from our earlier article.
Can we still claim to have a faster PlayerPrefs implementation?
When claiming to have a fast PlayerPrefs implementation, you need to be able to back it up with data. Since writing the previous blog post about our PlayerPrefs implementation, the Unity PlayerPrefs implementation no longer writes data to disk each time you set a value. Instead, Unity added a save method, which our implementation also has. But is our save method faster then the Unity PlayerPrefs’ implementation, or do we lose our title of fast PlayerPrefs?
To test this, we’ve set up a simple script that sets a defined amount of PlayerPrefs and saves it.
Performance in the Unity Editor
Timing the saves gives us the following results (performed in the Unity editor on a MacBook Pro with SSD).
The PreviewLabs PlayerPrefs class clearly outperforms the Unity PlayerPrefs when it comes to saving: it’s a difference between O(n) and O(n^2) – linear growth versus exponential. This could become an issue when saving more than a couple of thousand values. Otherwise, the Unity PlayerPrefs seem to be doing an adequate job.
Performance on Mobile
When we ran our test on mobile devices (iPad 3 and the 2012 version of the Google Nexus 7), noticed the following:
- The Unity PlayerPrefs are a few milliseconds faster when saving – so Unity did actually improve their implementation on mobile, compared to what is used in the Editor.
- Setting values is a lot slower in the Unity PlayerPrefs – this is done in linear time, compared to near-constant time in our implementation. When setting a few PlayerPrefs on a per-frame basis, this certainly does eat away valuable milliseconds.
Other differences noticed:
- The time it takes to save after deleting all keys is drastically different. With Unity’s implementation the time depends on the number of changes, while with PreviewLabs’s implementation it depends on the amount of keys currently in the PlayerPrefs.
- The Unity PlayerPrefs automatically loads the PlayerPrefs when starting the application, while the PreviewLabs PlayerPrefs does this when first accessing the class. This gives you additional control.
- The Unity PlayerPrefs still only supports string, integer and float values. The PreviewLabs PlayerPrefs adds boolean values to that list.
- We added an encryption option to our PlayerPrefs implementation. This allows developers to protect the data inside the PlayerPrefs from edits by the user or malicious practices. This option is missing in the Unity PlayerPrefs.
Conclusion: If you need to save or set a lot of values in the PlayerPrefs it is best to go for our implementation, otherwise still go for our implementation as it also allows you to save boolean values.