16GB+ for IndexedDB In Chrome under editor.construct.net ?

Post reply
0 favourites
  • 14 posts
From the Asset Store
Target 2.0 Slot HTML5 Construct 2 and Construct 3
$15 USD
Casino? money? who knows? but the target is the same!
bellborn's avatar
bellborn

  • So this is kind of just FYI but also maybe a question to Ashley that maybe users need to be made more aware of the need to manage this storage area.

    So I have been having a few issues with construct in chrome recently.

    Namely Various messages related to memory or storage like "not enough storage space" and also continually "serialized number too big"

    There is over 100GB free on my SSD so that's not the issue

    also I cleared the chrome cache (chrome advanced settings) but no joy

    Digging around I found that under dev tools > application > Storage > IndexedDB (when in editor.construct.net tab)

    this storage location was allocated up to 16GB of space and there was an indication that it was "full"

    there was an option to delete this data so I did and now no more messages about storage or serialized numbers.

    also it feels that the editor and also game previews are running faster/ snappier (have no way to verify this though may be my imagination)

    I assume that this IndexedDB is maybe the local storage for saved exports, projects, offline versions of the editor i dont know , also it appears to be used by the editor when running, but yea maybe there is a need for users to be more aware of the need to manage this storage area.

  • thanks for sharing! i think i talked about something similar a couple of weeks ago, a user on forum was having some mobile problems with memory full, and i kept saying might be the caching storage, not the ram or vram, as those he mentioned has plenty off.

    but i didn't knew about this indexdb i was just suggesting clearing the data in the history/clear cached data (images and other stuff)

  • yea it doesn't seem to be actual local storage as it doesn't get cleared when clearing cache in settings (which normally clears local storage). I looked into it a little apparently it is for use by web apps for more robust storage of larger files but yea much tech stuff above my pay grade...

  • yea it doesn't seem to be actual local storage as it doesn't get cleared when clearing cache in settings (which normally clears local storage). I looked into it a little apparently it is for use by web apps for more robust storage of larger files but yea much tech stuff above my pay grade...

    have you tried the browser audit performance option? found in f12 chrome or developer tools audit... i just swapped on desktop and applied cpu + memory throttle i wonder if that helps... i don't have a 1000 event sheet template to run it atm.

  • are we in the right thread? im at work at the moment on a work machine, cant do any recording or anything like that and the construct website is the only one that is not blocked (they haven't figured out it is game related yet I suppose) will try the 1000+ event sheet tonight on the MSPro4, and do a dev tools performance record. the performance recording usually hits the MSpro4 quite hard but if it runs on that thing (while doing a performance record) then it should run well on pretty much anything. will try to post back tonight if not on the weekend.

  • Sorry just got what you were saying! . Throttle using performance audit. Not the sharpest tool in the box me.

    Let me go home now, play daddy for a few hours, then check the surface pro. it maybe a graphix capability thing and the surface will show that for sure.

  • Sorry just got what you were saying! . Throttle using performance audit. Not the sharpest tool in the box me.

    Let me go home now, play daddy for a few hours, then check the surface pro. it maybe a graphix capability thing and the surface will show that for sure.

    don't worry i tested it out, is just an audit for testing surtain apps that run in browser.... i runned it on C3... ehm... outside some css and js loading slower cause of size... there is nothing to it... monitoring heap snapshots and other stuff killed the browser so don't worry about it really ^_^ continue the daddy play

  • Construct stores several types of data locally, mostly in indexeddb ( which for the uninitiated is persistent database managed by the browser that is saved locally on the computer/tablet/phone ).

    1. Itself: Construct caches the files to run itself locally so that it can run offline, which typically doesn't take up that much space. I believe we cache the last 5 versions that you have visited, but Ash will have to confirm that
    2. Demo projects: the projects that you can view on the start page are downloaded and stored in indexeddb as required.
    3. Browser saves: when you save to "the browser" it goes in indexeddb
    4. Recent exports: recent exports are viewable in the export manager and are saved in local storage, up to 10 exports are held and the oldest is deleted if you have more
    5. NWJS files: when doing NWJS exports the files required to build that version are downloaded and stored in indexeddb. These are quite large, so it makes sense to store them locally instead of downloading them each time.
    6. Layout: in construct layout customisation is split into 2 parts: overall and project. The overall layout ( sizes of bars and positions ) is stored in local storage, project is stored in the project file itself.
    7. Recent projects: a list of recent projects and where they are saved is stored locally, so we can show you the recent project menu

    Just to reiterate all this data is stored locally on your computer so we have no access to it. Most of the large things on the list (NWJS files, recent exports, Browsers saves) have menus you can view them, how much space they are using and have options to delete individual items. Hopefully this will help you narrow down what is using all that space. You can also clear the layout customisation in the settings menu, but that is unlikely to regain you any space.

    We don't directly move objects to the disk as any sort of optimisation, but we make heavy use of "Blob" objects. Blobs are similar to files, but just loose ( not in folders or any kind of filesystem ). Due to the way they are designed the contents of the blob don't have to be in RAM, so some browsers may transfer blobs (temporarily) that aren't being actively used to the disk to reduce memory pressure. We don't have any control over this process, but I imagine it's unlikely to cause any storage issues. It also won't be included in the storage quota for a domain, or be deleted when you use "clear site data".

  • Nepeo don't backups to the "Browser" location also go in IndexedDB? The only thing I can think of that would get clogged up with gigabytes of local storage is if there are endless local backups that aren't being cleaned up. Additionally I've no idea where the OK dialog with the "serialized value too large" error message could come from - it looks like a dialog that simply displays the contents of an error as its message, which we should avoid (it makes no sense to the user and can't be translated). In fact if people are saying it appears randomly, maybe that's the backup timer kicking off at periodic intervals...

  • Ashley They do yes, but they are treated quite similar to normal saves which is why I didn't mention them ( you can view, open and delete them in the browser save/open dialog ). There should only ever have 1 autosave file per project as it overwrites previous versions when it autosaves, so a user would have to have a lot of large projects to generate 16GB worth of saves. I expect the "serialized value too large" error is being caused by the autosave when it's trying to save to indexeddb ( but there is no space ). At the moment when experiencing an unknown save error we quite often spit out the internal cause, I've been meaning to change this but it makes passing known error messages more complicated.

  • Hi Nepeo

    re

    There should only ever have 1 autosave file per project as it overwrites previous versions when it autosaves

    So this may be of interest to you .... This is the way I work with construct 3

    1) I have auto backups set to "Save to Browser" at 10 minute intervals.

    This is the best way for the short interval backup IMO as it happens in the background so does not interfere with workflow and gives me the best peace of mind that if anything goes wrong in short term I have a very recent copy.

    2) Every , say 30-60 minutes, or after I have made a major change, then I will "Download a Copy"

    This is the best for regular saving as it puts a physical copy on my hard drive and due to the nature of "Download" always gives it a new sequential number ( i really love this aspect of using Download) so I am not overwriting any previous file. every save i make will automatically be its own file with a new number suffix.

    eg.

    3) at the end of every session I save a copy to the cloud.

    When returning to my project I always use the latest sequentially numbered file in the Downloads folder

    This means that my project always has a new file name every time I open it.

    This is the filename used when Construct makes the automatic Backup to the Browser.

    (Note that I very rarely use the Browser Backups I am just happy knowing that they are there. And yes they have saved my life on a few occasions.)

    My project is currently running at about 180MB save

    AS the project filename is always different, every time I use Construct the auto backup adds another 180 MB to IndexedDB

    So not including anything else like exports etc, using construct 88 times will fill indexeddb >16GB (which appears to be max allowed by chrome)

  • When you are creating/opening a totally new project of 180mb 88 times in a row will fill your memory does not sounds surprising. Cause that is basically what you are doing.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Yea but no but….

    1) General users are not aware of indexeddb

    2) Indexeddb also gets filled up with exports and other stuff

    3) It does not get deleted when deleting cache under advanced settings (which is as far as most users would venture and where most users assume all app data is stored)

    4) It can only be deleted under dev tools or reduced/deleted through features of the app that created it.

    5) It appears to have a max capacity of 16GB (I don’t know if this can be changed)

    6) There is no warning when it is full or near to full.

    7) When it is full it starts to cause storage issues with the app (and perhaps other areas of chrome) and gives cryptic messages with no indication of the issue.

    Yes maybe I just happened on it early due to the way I manage project saves but all regular Construct 3 users will likely come across this issue at some stage.

  • FYI the About dialog shows how much storage you're using and the quota available. The quota is not fixed at 16 GB; it is calculated as a proportion of the free space on the disk (e.g. for me it shows the quota is 31 GB). So you can probably increase the quota by cleaning up files and freeing up more space on the disk.

Post reply
  • 14 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)