ngStorage icon indicating copy to clipboard operation
ngStorage copied to clipboard

Performance issues with large content

Open razyalov opened this issue 9 years ago • 3 comments

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.

razyalov avatar Aug 25 '16 15:08 razyalov

$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.

egilkh avatar Aug 26 '16 08:08 egilkh

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 [email protected] 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.

razyalov avatar Aug 26 '16 15:08 razyalov

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.

artuska avatar Feb 16 '17 15:02 artuska