@pirijan Have you considered IndexedDB for storing data locally instead of localStorage
IMO RoamResearch is using it for storing large data with high performance.
I faced some lag with 500 cards in a Kinopio space.
2 Likes
2 Likes
I’ll look into that
Edit: looks like safari 14 support isn’t quite there yet https://caniuse.com/?search=indexdb
2 Likes
Yeah, I do as well. But I wonder whether if localStorage performance is what slows spaces with lots of cards down. have you measured that, @pirijan?
My understanding of IndexedDB is that it’s a mechanism for storing app data more persistently. You can use it with web workers, so you can do things async. But on the topic of IndexedDB and performance, I just saw this project by James Long, born out of his frustration with IndexedDB, esp its performance: A future for SQL on the web
1 Like
I haven’t measured anything , that would be a pre-requisite before doing more. That said there are bigger bottlenecks to look into
2 Likes
My money’s on the DOM
2 Likes
Now I’m going to stand with you 
from my tests , saving and updating even huge localstorage keyvalue pairs is always less than a millisecond so it’s def not a performance bottleneck
apparently, thanks to safari, indexdb shares the same major problems as localstorage The pain and anguish of using IndexedDB: problems, bugs and oddities · GitHub
1 Like
The main , and significant , advantage of indexedb is that it can hold a lot more data. But just like localstorage, it can’t be trusted to be persistent.
1 Like
GitHub - jakearchibald/idb-keyval: A super-simple-small promise-based keyval store implemented with IndexedDB looks like a really good lib to use to make the transition to indexdb
as recommended by justgage in Discord
slowly chipping away at this in cache uses indexedDB by pketh · Pull Request #569 · kinopio-club/kinopio-client · GitHub
1 Like
i continue to chip away at this . Because indexeddb is async and localstorage is not, there’s a lot of refactoring involved with all the methods that get/save things with cache.js
1 Like
made good progress on this today
2 Likes
finally released!
the first time you restart kinopio you’ll see a log message that starts with 🥂 migrated from ls to idb with some object details. you can also inspect your new indexeddb from the browser in the devtools storage tab. Besides that, things should not be noticeable.
implementation notes:
I used the idb-keyvalue lib to abstract away db things, but it wasn’t a drop in replacement because unlike ls, idb is async. A core assumption of the app is that local caching was synchronous (e.g. vuex mutations and vue computed values don’t support async), so this ended up being a huge project that refactored almost every part of the app to support async caching (cache uses indexedDB by pketh · Pull Request #569 · kinopio-club/kinopio-client · GitHub)
1 Like