Re: Structured clone in WebStorage
On Sat, Dec 4, 2010 at 1:23 AM, João Eiras joao.ei...@gmail.com wrote: On , Darin Fisher da...@chromium.org wrote: I will also add that I think WebStorage (well LocalStorage) is terrible from a performance point of view because it is synchronous, and I'd be very happy if we could discourage its usage and give people more reasons to adopt a better API like IndexedDB. -Darin I don't understand how storing values in a hash map is performant terrible. One of the smaller performance problems with LocalStorage: You have to take a snapshot of that object synchronously. Even with optimizations like copy on write, complex objects can take a while to make such a snapshot of. But the much bigger problem is that LocalStorage is shared between multiple windows. To maintain run to completion, LocalStorage (and cookies) are specced to require taking a storage mutex (a global lock) upon first use of LocalStorage (or cookies) and holding it until JavaScript completes running. So if two windows are both accessing LocalStorage they'll lock up each other and anything else running in their event loop. IE and Chrome are the only two browsers with multiple event loops at the moment. Google Chrome has no intention of ever implementing the storage mutex and my understanding is that IE is the same. So, to answer your question, most of the performance issue is a lock contention one. And because of this, LocalStorage is (and very likely will always be) racy on 2 major browsers. And as more browser adopt multi-process architectures, I expect they'll follow suit. J
Re: Structured clone in WebStorage
On Sun, Dec 5, 2010 at 9:47 PM, Jeremy Orlow jor...@chromium.org wrote: On Sat, Dec 4, 2010 at 1:23 AM, João Eiras joao.ei...@gmail.com wrote: On , Darin Fisher da...@chromium.org wrote: I will also add that I think WebStorage (well LocalStorage) is terrible from a performance point of view because it is synchronous, and I'd be very happy if we could discourage its usage and give people more reasons to adopt a better API like IndexedDB. -Darin I don't understand how storing values in a hash map is performant terrible. One of the smaller performance problems with LocalStorage: You have to take a snapshot of that object synchronously. Even with optimizations like copy on write, complex objects can take a while to make such a snapshot of. But the much bigger problem is that LocalStorage is shared between multiple windows. To maintain run to completion, LocalStorage (and cookies) are specced to require taking a storage mutex (a global lock) upon first use of LocalStorage (or cookies) and holding it until JavaScript completes running. So if two windows are both accessing LocalStorage they'll lock up each other and anything else running in their event loop. IE and Chrome are the only two browsers with multiple event loops at the moment. Google Chrome has no intention of ever implementing the storage mutex and my understanding is that IE is the same. So, to answer your question, most of the performance issue is a lock contention one. And because of this, LocalStorage is (and very likely will always be) racy on 2 major browsers. And as more browser adopt multi-process architectures, I expect they'll follow suit. You asked only about storing values, but note that reading values has problems as well. Either the browser needs to read all LocalStorage data into memory before running any scripts in the page or it's likely that your page will need to block on reading data from disk when it does use LocalStorage. J
Re: Structured clone in WebStorage
Have you guys considered what happens when a Blob is present? I'm very concerned about that case since WebStorage is a synchronous API. If storing a Blob in LocalStorage involves synchronous disk IO, then I'm pretty sure it is something I would object to implementing. I don't think there is a hand-wavy answer about performing a file copy asynchronously in the background. What if the file copy fails? -Darin On Thu, Dec 2, 2010 at 1:45 PM, Anne van Kesteren ann...@opera.com wrote: On Thu, 02 Dec 2010 21:51:29 +0100, Maciej Stachowiak m...@apple.com wrote: We think this feature would be straightforward to implement in Safari/WebKit, and we think it is a useful feature. We would like to implement it at some point. I can't give a specific timeline. I am not sure if it is straightforward to implement in Opera, but this applies to us as well. -- Anne van Kesteren http://annevankesteren.nl/
Re: Structured clone in WebStorage
I will also add that I think WebStorage (well LocalStorage) is terrible from a performance point of view because it is synchronous, and I'd be very happy if we could discourage its usage and give people more reasons to adopt a better API like IndexedDB. -Darin On Fri, Dec 3, 2010 at 10:41 AM, Darin Fisher da...@chromium.org wrote: Have you guys considered what happens when a Blob is present? I'm very concerned about that case since WebStorage is a synchronous API. If storing a Blob in LocalStorage involves synchronous disk IO, then I'm pretty sure it is something I would object to implementing. I don't think there is a hand-wavy answer about performing a file copy asynchronously in the background. What if the file copy fails? -Darin On Thu, Dec 2, 2010 at 1:45 PM, Anne van Kesteren ann...@opera.comwrote: On Thu, 02 Dec 2010 21:51:29 +0100, Maciej Stachowiak m...@apple.com wrote: We think this feature would be straightforward to implement in Safari/WebKit, and we think it is a useful feature. We would like to implement it at some point. I can't give a specific timeline. I am not sure if it is straightforward to implement in Opera, but this applies to us as well. -- Anne van Kesteren http://annevankesteren.nl/
Re: Structured clone in WebStorage
I recall talking to hixie about this at some point, and I recall that at that point localstorage was explicitly prevented from Blobs, although I can't see any sign of that rule anymore :-/ --Oliver On Dec 3, 2010, at 10:41 AM, Darin Fisher wrote: Have you guys considered what happens when a Blob is present? I'm very concerned about that case since WebStorage is a synchronous API. If storing a Blob in LocalStorage involves synchronous disk IO, then I'm pretty sure it is something I would object to implementing. I don't think there is a hand-wavy answer about performing a file copy asynchronously in the background. What if the file copy fails? -Darin On Thu, Dec 2, 2010 at 1:45 PM, Anne van Kesteren ann...@opera.com wrote: On Thu, 02 Dec 2010 21:51:29 +0100, Maciej Stachowiak m...@apple.com wrote: We think this feature would be straightforward to implement in Safari/WebKit, and we think it is a useful feature. We would like to implement it at some point. I can't give a specific timeline. I am not sure if it is straightforward to implement in Opera, but this applies to us as well. -- Anne van Kesteren http://annevankesteren.nl/
Re: Structured clone in WebStorage
On Fri, 3 Dec 2010, Oliver Hunt wrote: I recall talking to hixie about this at some point, and I recall that at that point localstorage was explicitly prevented from Blobs, although I can't see any sign of that rule anymore :-/ Blobs are fine, they're async anyway. To store one you'd just need to let the blob know that you need a checkpoint. The actual storage in localStorage can all be done in the background. The feature that was problematic with localStorage wasn't Blobs, it was ImageData, and that should still be blocked. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Structured clone in WebStorage
On , Darin Fisher da...@chromium.org wrote: I will also add that I think WebStorage (well LocalStorage) is terrible from a performance point of view because it is synchronous, and I'd be very happy if we could discourage its usage and give people more reasons to adopt a better API like IndexedDB. -Darin I don't understand how storing values in a hash map is performant terrible.
Re: Structured clone in WebStorage
On Nov/29/2010 9:59 AM, ext Adrian Bateman wrote: On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote: For over a year now, the WebStorage spec has stipulated that Local/SessionStorage store and retrieve objects per the structured clone algorithm rather than strings. And yet there isn't a single implementation who's implemented this. I've talked to people in the know from several of the other major browsers and, although no one is super against implementing it (including us), no one has it on any of their (even internal) roadmaps. It's just not a high enough priority for anyone at the moment. I feel pretty strongly that we should _at least_ put in some non-normative note that no browser vendor is currently planning on implementing this feature. Or, better yet, just remove it from the spec until support starts emerging. I agree. We have no plans to support this in the near future either. At the very least, I think this should be noted as a feature at risk in the Call for Implementations [1]. I don't have a strong preference for removing this feature or marking it as a Feature At Risk when the Candidate is published. It would be good to get feedback from other implementers (Maciej?, Jonas?, Anne?). If no one plans to implement it, perhaps it should just be removed. -Art Barstow
Re: Structured clone in WebStorage
On Thu, Dec 2, 2010 at 5:45 AM, Arthur Barstow art.bars...@nokia.com wrote: On Nov/29/2010 9:59 AM, ext Adrian Bateman wrote: On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote: For over a year now, the WebStorage spec has stipulated that Local/SessionStorage store and retrieve objects per the structured clone algorithm rather than strings. And yet there isn't a single implementation who's implemented this. I've talked to people in the know from several of the other major browsers and, although no one is super against implementing it (including us), no one has it on any of their (even internal) roadmaps. It's just not a high enough priority for anyone at the moment. I feel pretty strongly that we should _at least_ put in some non-normative note that no browser vendor is currently planning on implementing this feature. Or, better yet, just remove it from the spec until support starts emerging. I agree. We have no plans to support this in the near future either. At the very least, I think this should be noted as a feature at risk in the Call for Implementations [1]. I don't have a strong preference for removing this feature or marking it as a Feature At Risk when the Candidate is published. It would be good to get feedback from other implementers (Maciej?, Jonas?, Anne?). If no one plans to implement it, perhaps it should just be removed. I won't be the person implementing it, but fwiw I highly value having structured clones actually work. Any time I talk about localStorage or similar, I get people asking about storing non-string data, and not wanting to have to futz around with rolling their own serialization. ~TJ
Re: Structured clone in WebStorage
On Thu, Dec 2, 2010 at 5:06 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Dec 2, 2010 at 5:45 AM, Arthur Barstow art.bars...@nokia.com wrote: On Nov/29/2010 9:59 AM, ext Adrian Bateman wrote: On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote: For over a year now, the WebStorage spec has stipulated that Local/SessionStorage store and retrieve objects per the structured clone algorithm rather than strings. And yet there isn't a single implementation who's implemented this. I've talked to people in the know from several of the other major browsers and, although no one is super against implementing it (including us), no one has it on any of their (even internal) roadmaps. It's just not a high enough priority for anyone at the moment. I feel pretty strongly that we should _at least_ put in some non-normative note that no browser vendor is currently planning on implementing this feature. Or, better yet, just remove it from the spec until support starts emerging. I agree. We have no plans to support this in the near future either. At the very least, I think this should be noted as a feature at risk in the Call for Implementations [1]. I don't have a strong preference for removing this feature or marking it as a Feature At Risk when the Candidate is published. It would be good to get feedback from other implementers (Maciej?, Jonas?, Anne?). If no one plans to implement it, perhaps it should just be removed. I won't be the person implementing it, but fwiw I highly value having structured clones actually work. Any time I talk about localStorage or similar, I get people asking about storing non-string data, and not wanting to have to futz around with rolling their own serialization. The spec should reflect reality and not be a collection of cool ideas that may or may not ever be implemented. I'm not arguing the merits of the feature, I'm arguing that until at least a single vendor starts implementing this, it's confusing for developers to see such text in the spec--especially so when said text has been there for over a year. J
Re: Structured clone in WebStorage
* Tab Atkins Jr. wrote: I won't be the person implementing it, but fwiw I highly value having structured clones actually work. Any time I talk about localStorage or similar, I get people asking about storing non-string data, and not wanting to have to futz around with rolling their own serialization. For most who'd consider rolling their own, JSON.stringify would seem to be a viable alternative. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Structured clone in WebStorage
On Thu, Dec 2, 2010 at 5:45 AM, Arthur Barstow art.bars...@nokia.com wrote: On Nov/29/2010 9:59 AM, ext Adrian Bateman wrote: On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote: For over a year now, the WebStorage spec has stipulated that Local/SessionStorage store and retrieve objects per the structured clone algorithm rather than strings. And yet there isn't a single implementation who's implemented this. I've talked to people in the know from several of the other major browsers and, although no one is super against implementing it (including us), no one has it on any of their (even internal) roadmaps. It's just not a high enough priority for anyone at the moment. I feel pretty strongly that we should _at least_ put in some non-normative note that no browser vendor is currently planning on implementing this feature. Or, better yet, just remove it from the spec until support starts emerging. I agree. We have no plans to support this in the near future either. At the very least, I think this should be noted as a feature at risk in the Call for Implementations [1]. I don't have a strong preference for removing this feature or marking it as a Feature At Risk when the Candidate is published. It would be good to get feedback from other implementers (Maciej?, Jonas?, Anne?). If no one plans to implement it, perhaps it should just be removed. I personally would like to see it implemented in Firefox (and other browsers), but I don't feel super strongly. It's something that we likely will be discussing in a few weeks here at Mozilla. One important data-point if the timeline for adding structured-clones to localStorage has similar or longer timeline than adding support for IndexedDB for the various browsers... / Jonas
Re: Structured clone in WebStorage
On Thu, Dec 2, 2010 at 6:29 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Dec 2, 2010 at 5:45 AM, Arthur Barstow art.bars...@nokia.com wrote: On Nov/29/2010 9:59 AM, ext Adrian Bateman wrote: On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote: For over a year now, the WebStorage spec has stipulated that Local/SessionStorage store and retrieve objects per the structured clone algorithm rather than strings. And yet there isn't a single implementation who's implemented this. I've talked to people in the know from several of the other major browsers and, although no one is super against implementing it (including us), no one has it on any of their (even internal) roadmaps. It's just not a high enough priority for anyone at the moment. I feel pretty strongly that we should _at least_ put in some non-normative note that no browser vendor is currently planning on implementing this feature. Or, better yet, just remove it from the spec until support starts emerging. I agree. We have no plans to support this in the near future either. At the very least, I think this should be noted as a feature at risk in the Call for Implementations [1]. I don't have a strong preference for removing this feature or marking it as a Feature At Risk when the Candidate is published. It would be good to get feedback from other implementers (Maciej?, Jonas?, Anne?). If no one plans to implement it, perhaps it should just be removed. I personally would like to see it implemented in Firefox (and other browsers), but I don't feel super strongly. It's something that we likely will be discussing in a few weeks here at Mozilla. My understanding is that many people across many browsers have thought it was a cool idea and would have been happy to have seen it implemented. But no one has done so. Which is why I think we should _at least_ add a non-normative note stating the situation to the spec. Once it's being implemented then, by all means, we can remove it. But who knows how much longer it'll be before anyone actually implements it. One important data-point if the timeline for adding structured-clones to localStorage has similar or longer timeline than adding support for IndexedDB for the various browsers... There is a 99.99% chance Chromium will be shipping IndexedDB before structured clone support for local storage. And there's almost no chance we'll be the first to ship structured clone support for local storage, but we'll likely follow if/when others do. J
Re: Structured clone in WebStorage
On Dec 2, 2010, at 5:45 AM, Arthur Barstow wrote: On Nov/29/2010 9:59 AM, ext Adrian Bateman wrote: On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote: For over a year now, the WebStorage spec has stipulated that Local/SessionStorage store and retrieve objects per the structured clone algorithm rather than strings. And yet there isn't a single implementation who's implemented this. I've talked to people in the know from several of the other major browsers and, although no one is super against implementing it (including us), no one has it on any of their (even internal) roadmaps. It's just not a high enough priority for anyone at the moment. I feel pretty strongly that we should _at least_ put in some non-normative note that no browser vendor is currently planning on implementing this feature. Or, better yet, just remove it from the spec until support starts emerging. I agree. We have no plans to support this in the near future either. At the very least, I think this should be noted as a feature at risk in the Call for Implementations [1]. I don't have a strong preference for removing this feature or marking it as a Feature At Risk when the Candidate is published. It would be good to get feedback from other implementers (Maciej?, Jonas?, Anne?). If no one plans to implement it, perhaps it should just be removed. We think this feature would be straightforward to implement in Safari/WebKit, and we think it is a useful feature. We would like to implement it at some point. I can't give a specific timeline. Regards, Maciej
Re: Structured clone in WebStorage
On Dec 2, 2010, at 10:41 AM, Jeremy Orlow wrote: On Thu, Dec 2, 2010 at 6:29 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Dec 2, 2010 at 5:45 AM, Arthur Barstow art.bars...@nokia.com wrote: On Nov/29/2010 9:59 AM, ext Adrian Bateman wrote: On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote: For over a year now, the WebStorage spec has stipulated that Local/SessionStorage store and retrieve objects per the structured clone algorithm rather than strings. And yet there isn't a single implementation who's implemented this. I've talked to people in the know from several of the other major browsers and, although no one is super against implementing it (including us), no one has it on any of their (even internal) roadmaps. It's just not a high enough priority for anyone at the moment. I feel pretty strongly that we should _at least_ put in some non-normative note that no browser vendor is currently planning on implementing this feature. Or, better yet, just remove it from the spec until support starts emerging. I agree. We have no plans to support this in the near future either. At the very least, I think this should be noted as a feature at risk in the Call for Implementations [1]. I don't have a strong preference for removing this feature or marking it as a Feature At Risk when the Candidate is published. It would be good to get feedback from other implementers (Maciej?, Jonas?, Anne?). If no one plans to implement it, perhaps it should just be removed. I personally would like to see it implemented in Firefox (and other browsers), but I don't feel super strongly. It's something that we likely will be discussing in a few weeks here at Mozilla. My understanding is that many people across many browsers have thought it was a cool idea and would have been happy to have seen it implemented. But no one has done so. Which is why I think we should _at least_ add a non-normative note stating the situation to the spec. Once it's being implemented then, by all means, we can remove it. But who knows how much longer it'll be before anyone actually implements it. I don't think it is necessary for specs to include non-normative notes about the current implementation status of particular features. I would be ok with marking the feature at risk if it still lacks implementations by the time Web Storage goes to CR. Regards, Maciej
Re: Structured clone in WebStorage
On Thu, 02 Dec 2010 21:51:29 +0100, Maciej Stachowiak m...@apple.com wrote: We think this feature would be straightforward to implement in Safari/WebKit, and we think it is a useful feature. We would like to implement it at some point. I can't give a specific timeline. I am not sure if it is straightforward to implement in Opera, but this applies to us as well. -- Anne van Kesteren http://annevankesteren.nl/
RE: Structured clone in WebStorage
On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote: For over a year now, the WebStorage spec has stipulated that Local/SessionStorage store and retrieve objects per the structured clone algorithm rather than strings. And yet there isn't a single implementation who's implemented this. I've talked to people in the know from several of the other major browsers and, although no one is super against implementing it (including us), no one has it on any of their (even internal) roadmaps. It's just not a high enough priority for anyone at the moment. I feel pretty strongly that we should _at least_ put in some non-normative note that no browser vendor is currently planning on implementing this feature. Or, better yet, just remove it from the spec until support starts emerging. I agree. We have no plans to support this in the near future either. At the very least, I think this should be noted as a feature at risk in the Call for Implementations [1]. Adrian. [1] http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
