Saving option page values: JSON.stringify() or straight to localstorage?

[iron2000]

Most of the extensions I see save their option page values using JSON.stringify() then putting that one long string into the localStorage.

Is there any benefit compared to each option page value having their own localStorage string?

Does will JSON.parse() slow down the extension?

It seems like like storing the JSON.parse() once will lead to outdated option page values.

If each function in the js need some option page value and JSON.parse() is called in every one of those functions, will it be slow(like more then 1 second?)?

If theres 3 js (say bg,options,popup) files with a few functions each and they all call JSON.parse() for an option page value?

From what I see JSON seems to be an extra step.

[Joe Marini]

They probably do it as a convenience feature, since they're tracking their options in a JSON object structure. This approach won't noticeably slow down the extension. 

By the way, it's probably better to use chrome.storage APIs, since you can sync your extension settings across Chrome sessions like the application itself does.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/R-LoFW1yJzAJ.
To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.

--
Joe Marini

Developer Advocate / Chrome

joem...@google.com | +Joe Marini | @joemarini

[Matt Kruse]

Since storage operations are async, you often need to get multiple options at the same time, and you don't want to fire them as separate requests. It's easier to retrieve and store your whole preference structure as one JSON object. Using the chrome.storage.* API, you don't even have to parse/stringify the JSON, you can just store it directly.

The only issue I have right now is that each tab reads in its own JSON object from preferences, and stores it. So if another tab changes an option, the first tab doesn't see that change. So right now, whenever I update a value, I first retrieve my JSON, then update it. It's an extra step but doesn't seem to impact performance.

Matt Kruse

[iron2000]

Are there any speed benefits between JSON.stringify, straight to localSorage and chrome.storage API?

Or there is no difference at all as everything is run on the client side?

Looked at the chrome.storage API and it seems troublesome to use.

I prefer operating straight on localStorage.something and have changes go automatically to localStorage.

To me those set and get methods add another layer of complication to the mix.

[iron2000]

Was researching and found this:

http://jsperf.com/localstorage-1-object-vs-many-keys1

Seems to suggest that JSON.stringify is faster than straught to localStorage.

[kalman]

chrome.storage uses JSON stringification under the hood, at least for now.

However, the reason localStorage is inefficient setting multiple keys is presumably because it's synchonous. For each write, JavaScript needs to wait on a round trip to the browser including writing that data to disk. It's better to do that in one blob rather than multiple writes.

chrome.storage on the other hand is asynchronous and won't block your script while it's writing to disk.

So -- it's it is highly unlikely that JSON stringification of any sort will be a bottleneck particularly in storage code -- more likely is that it will be IO / IPC overhead / general JavaScript slowness overhead.

Also note: there are other reasons to use chrome.storage over localStorage besides speed, see http://developer.chrome.com/extensions/storage.html.

Cheers,

Ben.

[Eric Williams]

On 9/20/2012 3:08 PM, Matt Kruse wrote:
> Since storage operations are async, you often need to get multiple
> options at the same time, and you don't want to fire them as separate
> requests. It's easier to retrieve and store your whole preference
> structure as one JSON object. Using the chrome.storage.* API, you don't
> even have to parse/stringify the JSON, you can just store it directly.
>
> The only issue I have right now is that each tab reads in its own JSON
> object from preferences, and stores it. So if another tab changes an
> option, the first tab doesn't see that change. So right now, whenever I
> update a value, I first retrieve my JSON, then update it. It's an extra
> step but doesn't seem to impact performance.

It's possible to request a list of keys from chrome.storage by passing
an array of them, which avoids the multiple-requests issue without
introducing the problems using a single JSON object can cause.

[Aaron Boodman]

The benefit to using chrome.storage is that you can access the same
data from both content scripts and you background page.

With localStorage, if you want to access your data from content
scripts, you'll have a background page and a system of functions in
both the content script and the background page to marshall the data
to and from the background page.

Another benefit of chrome.storage is that your data can be
automatically synced.

- a

> --
> You received this message because you are subscribed to the Google Groups
> "Chromium-extensions" group.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/n3g4LSKYa6YJ.

[iron2000]

Does chrome.storage wrap on localStorage?

Or does it store data somewhere else?

Is the data still viewable in Chrome's devtools?

[kalman]

Does chrome.storage wrap on localStorage?

No, it is its own area separate from any other web storage.

 

Or does it store data somewhere else?

It stores it in the user's profile.

 

Is the data still viewable in Chrome's devtools?

Only by typing API calls into the console.