Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at during this transition time.

    It's still possible to reply to existing private message conversations during the migration, but any new replies you post will be missing after the main migration is complete. We'll do our best to migrate these messages in a follow-up step.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.

    Read our full announcement for more information and let us know if you have any questions.

Question Webgl memory

Discussion in 'Web' started by sebirch, May 23, 2023.

  1. sebirch


    Aug 11, 2017
    We are optimizing a web application, because of crash after reaching the famous 2gb level of memory.
    It's a web configurator for metallic sliding, builded with lots of instances.
    By reworking some part of code, and only using low poly version of metallic meshes, we manage to keep that limit.

    So far, the heap size doesn't lower, even if we use less memory, unless we reload the webpage.
    As that reloadign tooks too many seconds, is there a way to manually lower that size?

    Like in the picture example, where A shows a lighter use of memory after some manipulation, and B showing the state of memory after the refresh.

    Thank you for any research direction you know!

    Attached Files:

  2. CodeSmile


    Apr 10, 2014
    Nice to hear that you can actually get close to that 2gb limit. So far it's only been hearsay. ;)

    I assume this is on Windows? What browser? What build & player settings? Would be interesting to hear what the memory usage is between Chrome, Firefox, Edge and possibly others.

    Afaik you don't get to control anything manually in regards to WebGL runtime memory usage. You can only optimize the build for memory usage and check for memory leaks and manage loading/unloading assets respectively verifying that unloading actually occurs. If the memory size doesn't go back down without a refresh it doesn't indicate memory leaks though. This may simply be due to the browser caching, garbage collection, or whatever.

    I tend to advise to stay 25% below the memory budget to keep random web browser tech BS in check, mainly browser differences, browser version differences, browser config differences, differences in installed plugins, differences between OS and OS versions, caching, bugs, leaks - all of that may or may not affect memory usage so it's best to not take that 2GB limit literally. It's a hard limit and failures will happen even before getting close to it since this 2GB is for the entire tab (including any page HTML, images, scripts, etc) and not the Unity instance alone. But I suppose you already know that from looking at Memory Profiler.

    What about texture resizing and compression? See these settings in Build Settings dialog, it can't hurt to give those a try and see how it affects memory usage, and if the loss in quality is acceptable that would be the easiest way out.

    Other things you can try and see how far it affects memory usage is:
    • Lightmap Encoding: low quality (little to no impact in my tests)
    • Code generation: faster (smaller) builds
    • C++ compiler config: Master (don't know if that works with memory profiler but it's the configuration that you'll be using to publish the 'game')
    • Managed Stripping Level: High (may result in build or runtime errors => it cannot hurt to try and fix those)
    • Enable Exceptions: None
    • Compression format: Disabled may use less memory but takes longer to load of course
    • Debug Symbols: Off
    • Decompression Fallback: Off
    • Initial Memory Size: set it as high as possible to prevent dynamic allocations
    There may be more in this post / thread as I recently did some build size optimizations but I didn't check memory usage.

    Some of these settings may not be available to you. I'm on 2023.1 right now.
    It may also be worthwhile to run tests with 2022.2 since WebGL internals keep getting updates in every release, and 2022.3 LTS is just around the corner.
    Last edited: May 23, 2023
    GDevTeam likes this.