39

How fast are SharedPreferences? Is there a way to put them in memory for reading? I have a small amount of data that a ListView has to query to display each cell, and I'm worried that a call to flash memory will be too slow. I'm not worried about write speed, as writes will happen infrequently. I'm considering just using a JSON object to persist the data instead of SharedPreferences. Any thoughts?

CopsOnRoad
  • 237,138
  • 77
  • 654
  • 440
GLee
  • 5,003
  • 5
  • 35
  • 39
  • SharedPreferences is essentially a xml-file residing in the app "sandbox" storage. It can be accessed and viewed through ADB. – hakanostrom Oct 02 '13 at 23:21

5 Answers5

64

Is there a way to put them in memory for reading?

They are in memory, after the first reference. The first time you retrieve a specific SharedPreferences (e.g., PreferenceManager.getDefaultSharedPreferences()), the data is loaded from disk, and kept around.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • 2
    you say, the whole saved data in `SharedPreferences` will be loaded once you get instance of `PreferenceManager.getDefaultSharedPreferences()` ??? – Mohammad Ersan Oct 02 '13 at 23:28
  • 8
    @MoshErsan: Yes. The `SharedPreferences` is held in a static `HashMap` of `SharedPreferences` in `ContextImpl`. It will remain there until the process is terminated. See `sSharedPrefs` in https://github.com/android/platform_frameworks_base/blob/master/core/java/android/app/ContextImpl.java – CommonsWare Oct 02 '13 at 23:37
  • 1
    what is the benefit of doing it like this?!! – Mohammad Ersan Oct 02 '13 at 23:43
  • 2
    @MoshErsan: Among other things, it ensures that all components of your app, asking for the same `SharedPreferences`, get the actual same `SharedPreferences` instance, and so they cannot get out of sync with each other. – CommonsWare Oct 02 '13 at 23:47
  • 1
    I was reading `SharedPreferencesImpl`->`startLoadFromDisk`, in this case if we saved a big data in it, it may cause `OOE`. – Mohammad Ersan Oct 02 '13 at 23:50
  • 4
    @MoshErsan: Correct. `SharedPreferences` should be small. – CommonsWare Oct 02 '13 at 23:54
  • @MohammadErsan for some data it's better to use database (SQLite) and SharedPreferences for some settings. I don't think your apps have a lot of settings – user924 Oct 14 '18 at 15:36
  • bad answer, you still have to load from disk, even you have the reference. Gosh! – Ashton May 14 '20 at 11:48
  • @Devon: "you still have to load from disk" -- not according to [the source code](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/app/ContextImpl.java;l=181-186?q=ContextImpl&ss=android%2Fplatform%2Fsuperproject) and [the source code](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/app/SharedPreferencesImpl.java;l=74-75). Preferences and their values are cached. – CommonsWare May 14 '20 at 11:53
19

My advice is to test your performance first, and then start worrying about speed. In general, you'll be happier with an app that prioritizes maintainability as well as speed. When engineers start out to achieve performance before they get the app stable, the result is an app that runs a bit faster but has lots of bugs.

Joe Malin
  • 8,621
  • 1
  • 23
  • 18
15

According to this link, getSharedPreferences is not that much heavy because it opens file only when you call getSharedPreferences first time:

// There are 1000 String values in preferences

SharedPreferences first = context.getSharedPreferences("com.example.app", Context.MODE_PRIVATE);
// call time = 4 milliseconds

SharedPreferences second = context.getSharedPreferences("com.example.app", Context.MODE_PRIVATE);
// call time = 0 milliseconds

SharedPreferences third = context.getSharedPreferences("com.example.app", Context.MODE_PRIVATE);
// call time = 0 milliseconds

But using get methods will take some time for the first time you call it:

first.getString("key", null)
// call time = 147 milliseconds

first.getString("key", null)
// call time = 0 milliseconds

second.getString("key", null)
// call time = 0 milliseconds

third.getString("key", null)
// call time = 0 milliseconds
Milad Faridnia
  • 9,113
  • 13
  • 65
  • 78
0

Another benchmark for those interested in larger files. The snippet below run on a 2013(?) Samsung SMT-350 tablet (1.2 GHz Quad-Core, Qualcomm) revealed:

  • About 80 seconds to create 10000 7k strings
  • About 3.5 seconds to 'open' (getSharedPreferences) the 70mb file
  • About 1/10ms to read any 7k string once the SP was open

Note: the file creation crashed at 5500, but continued without problem. I am NOT recommending the use of 70MB SPs, this was for an unlikely edge case test, and 100x over-test.

        G.logTime("MAKE HUGE FILE", true);
        String sevenKString = App.getAsset(this, "sample_map.txt");
        SharedPreferences.Editor spf = getSharedPreferences("TEST", Context.MODE_PRIVATE).edit();
        G.logTime("SP OPEN", false);
        for (Integer i = 0; i < 10000; i++) {
            spf.putString(i.toString(), sevenKString);
            spf.apply();
            G.logTime("SP ADD " + i.toString() + " (" + (7 * i) + ")", false);
        }

        G.logTime("SP OPEN", true);
        SharedPreferences sp = getSharedPreferences("TEST", Context.MODE_PRIVATE);
        for (Integer i = 1; i < 10000; i += 10) {
            file = sp.getString(i.toString(), null);
            G.logTime("SP READ = " + i.toString(), false);
        }
Lorne K
  • 109
  • 7
-1

I have a small amount of data that a ListView has to query to display each cell

Can't you make a Singleton, a common class and read it from there from second time? I would do that.

  • 3
    There is no need to increase shared global state via Singletons. Android already has solutions for global state management via `SharedPreferences` and `Bundles`. It is enough. You should eliminate global state as much as you can – Oleksandr Karaberov Nov 12 '15 at 11:42