Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dialog stores data very inefficiently in localStorage #131

Open
3 of 5 tasks
curiousdannii opened this issue Jul 31, 2022 · 1 comment
Open
3 of 5 tasks

Dialog stores data very inefficiently in localStorage #131

curiousdannii opened this issue Jul 31, 2022 · 1 comment

Comments

@curiousdannii
Copy link
Owner

curiousdannii commented Jul 31, 2022

It was reported here that Counterfeit Monkey can have trouble saving/restoring save files, but it can happen to any storyfile: i7/counterfeit-monkey#191. More discussion on the forum.

The issue is that the localStorage is getting too full to store the save file, which is about 150KB, out of the total 5MB that the browser can store. If you've been playing lots of things in Parchment then even if you haven't been making lots of save files there could be lots of autosaves taking up space. Then when you try to restore, it fails because the save file is empty.

Parchment/Dialog could be storing data in localStorage much more efficiently, and it could be using IndexedDB, which has much bigger limits (over a GB I think), and it could also be evicting autosaves to make space. I have plans to make those sorts of changes (#11), but they're not short term plans, it will take a lot of work to get everything ready.

What can we do about this?

  • Without changing the whole Dialog system, we could make it store files more densely. Each byte currently takes up about ~3.5 characters, but it could be compressed using base32768 into ~0.5 characters/byte. (I was researching this literally 2 days ago.) That's an improvement of 7 times!
  • Autosaves should be split into two localStorage files - one for text and one for the ram. Both could be compressed using base32768.
  • Emglken currently stores data as latin-1 texts. These should be ported and accessed as Uint8Arrays, which means bumping the version of Emglken.
  • We could make it remove autosaves to free up space. It currently doesn't store dates for when autosaves were created/used, so we'd probably just have to delete all of them. Or we could add a date for each.
  • The various users of Glk need to check whether files were written successfully. I've reported this as a bug to the I7 tracker, but the other users all need to as well.
@curiousdannii
Copy link
Owner Author

Here are all the calls to file_write and file_read:

  • file_write

    • emglkenfs.js
      • close calls with raw data converted to an ASCII string
      • open calls with raw ""
    • glkapi.js
      • gli_stream_flush_file calls with Array<number>
      • glk_stream_close calls with Array<number>
      • glk_stream_open_file/glk_stream_open_file_uni calls with raw ""
      • restore_allstate calls with raw ""
  • file_read

    • emglkenfs.js
      • open calls with raw: true
    • glkapi.js
      • glk_stream_open_file/glk_stream_open_file_uni calls with raw: false
      • restore_allstate calls with raw: false

This is a good sign: aside from emglkenfs.js, raw mode is only ever used to set an empty file. So I'm thinking I'll consider uses of file_write that write a raw text other than "" to be deprecated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant