search

gsklee / ngStorage

localStorage and sessionStorage done right for AngularJS.
MIT License
2.33k stars 461 forks source link

Performance issues with large content #241

Open razyalov opened 8 years ago

razyalov commented 8 years ago

When the local storage grows into a large cache with big objects and more than 1.5k keys, it slows down the angular app dramatically (JavaScript locked for 0.5-1 second for the ngStorage sync operations) and this is on Chrome on the best MacBook Pro edition. Need to find a better way to reduce the sync overhead.

egilkh commented 8 years ago

$sync doesn't really have that much wiggle room to improve all that much as it is. As it is a blocking operation.

What I would suggest is moving it to $q and having 1 promise for each operation. Assuming $storage[] = deserializer() would not be blocking. Haven't tried it.

Not questioning your use case, but do you really need to have 1.5k keys and big objects in there? I would think you will hit bottlenecks for localStorage sooner or later.

razyalov commented 8 years ago

I use it as a local cache with the intention of being ok if it is too large as a cache. But because ngStorage is updating and comparing it all the time, any events rich operation like scrolling etc is hit on performance by ngStorage for some reason, and the apply cycles get very long after changes to the store.

I like the auto-boxing of objects into/from json but the sync operation just to keep the API the same as the native localStorage is a huge overkill for my use case.

On Aug 26, 2016, at 1:37 AM, egilkh notifications@github.com wrote:

$sync doesn't really have that much wiggle room to improve all that much as it is. As it is a blocking operation.

What I would suggest is moving it to $q and having 1 promise for each operation. Assuming $storage[] = deserializer() would not be blocking. Haven't tried it.

Not questioning your use case, but do you really need to have 1.5k keys and big objects in there? I would think you will hit bottlenecks for localStorage sooner or later.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

artuska commented 7 years ago

Not questioning your use case, but do you really need to have 1.5k keys and big objects in there?

Use case for big objects: ETag. I have to keep all request response data somewhere, e.g. in the session storage, so I can access them after the whole page refresh when all requests with If-None-Match header come back with empty data and Not Modified header because of ETag keys are equal and I have to use previously stored data from the session storage.