Is access to NSUserDefaults on iOS considered cheap?

Question

In short: fast / cheap? Does it make sense to store the value from NSUserDefaults in memory for faster access?

Longer: let's say I have a significant amount of values ​​that need to be saved and read from NSUserDefaults; with the need to often receive (read) these values.

In the snippet below, I initialize the private stored property and keep it synchronized with the corresponding NSUserDefaults value - so when I need to read it, I read the property.

If the default read directly is fast, I would obviously delete the private property. But I'm not so sure about that. Is it fast?

private var _loggedIn = NSUserDefaults.standardUserDefaults().boolForKey("loggedIn") public var loggedIn: Bool { get { return _loggedIn } set { _loggedIn = newValue NSUserDefaults.standardUserDefaults().setBool(newValue, forKey: "loggedIn") NSUserDefaults.standardUserDefaults().synchronize() } } 

Clarification for future readers: the question is about reading, and not about recording / synchronization, which (as indicated in the answers) is neither fast nor cheap.

.synchronize() is called on the setter for a good reason - in my particular case, it is important that it synchronizes immediately, so I sacrifice performance for logical integrity. In general, you should consider whether you need to call it — or let the system choose the right time for recording.

.. Actually, now when I look at it, I see that storing the saved property, as in the fragment, will ensure logical integrity (if access from other places is via getter, and not directly from userDefaults). Therefore, I can also avoid synchronizing .

Answer 1

Reading is cheap. There is generous caching in place, and everything happens in RAM. Mutation is relatively cheap, but the system will still have to store content in non-volatile memory (a .plist file on the flash) at regular intervals.

Explicit synchronization is not cheap. He eats time and more energy.

So for reading, this is normal, but with a lot of records, I still do it in a separate container and serialize only as needed.

Answer 2

This is unlikely to have a significant impact on performance, but you can profile it yourself with tools to ensure that the impact on performance is negligible.

Answer 3

I did some performance tests using tools, as @mipadi suggested last year, and my conclusion was that there was no significant difference.

As I noted in the comments above, it is very important to determine which of these NSUserDefaults entries we want to make right away. In these specific cases, use the synchronize method, otherwise IOS handles this work to get better performance.

Answer 4

Everything is fine if you are not using NSUserDefaults as a database. synchronize () will write the full plist file, so if you store megabytes of data and then synchronize heavily, performance and / or battery life will suffer.

But check out this question: How often are NSUserDefaults synchronized?

An interesting detail is that custom defaults will be recorded when your application terminates. Someone may be experimenting with what happens if your program crashes immediately after changing NSUserdefaults; if it is considered "completion".