Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice
  3. Join us on November 16th, 2023, between 1 pm and 9 pm CET for Ask the Experts Online on Discord and on Unity Discussions.
    Dismiss Notice
New Forum User Notice Update to the Unity Editor Software Terms Unite 2023 - Ask the Experts Online

WebGL Memory Usage

Discussion in 'WebGL' started by nwrobel, May 26, 2015.

  1. nwrobel

    nwrobel

    Joined:
    May 19, 2015
    Posts:
    4
    Hello,

    I have been building and running a small WebGL project for awhile and I've noticed that it uses a large amount of RAM when starting up. In Google Chrome (v 43), and similarly in firefox (v37), the webpage memory usage spikes to around 2.5 GB and then settles at around 500 MB. The unity canvas takes about 45 seconds to load in total. My project consists of a single scene in which I load a few cubes for testing. Is this just a bug since WebGL support is new?

    Thanks.
     
    nwrobel, May 26, 2015
    #1

  2. bajeo88

    bajeo88

    Joined:
    Jul 4, 2012
    Posts:
    64
    Im seeing the same thing. Small project of 1 scene with 1 low poly character and some UI buttons is loading and crashing when it uses over 3gb.

    I managed to get it to survive the loading process by making a development build (maxes out at about 2gb while loading) but it still uses 850mb in total. It appears to be "normal" for the moment but I would also be interested to know why it consumes such large amounts of memory on loading since it is causing high crash rates with a small project.
     
    bajeo88, May 28, 2015
    #2

  3. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    The issue with memory usage spiking at player load is caused by the browser requiring a lot of memory to parse all the JavaScript code. Basically, most JavaScript engines have not been designed with such big codebases in mind, so our use case is a bit extreme. There is work in motion across browser vendors to improve this situation, but, for now, the best and only thing you can do about it, really, is to make sure you emit as little code as possible, by enabling stripping, making Fast/Fastest release builds, and not using any large .NET dlls as plugins.
     
    jonas-echterhoff, May 29, 2015
    #3

  4. bajeo88

    bajeo88

    Joined:
    Jul 4, 2012
    Posts:
    64
    Thanks Jonas, your tip reduced the build to about 1/6 of the original size! :)
     
    bajeo88, May 29, 2015
    #4

  5. arumiat

    arumiat

    Joined:
    Apr 26, 2014
    Posts:
    321
    A question, my dev has implemented a streaming system using assetBundles. Is this likely to reduce the likelihood of getting an out of memory error, as only smaller files are being loaded each time?

    Thanks,
    A
     
    arumiat, May 31, 2015
    #5

  6. wbl1

    wbl1

    Joined:
    Apr 22, 2009
    Posts:
    159
    Jonas, you mention not using any large .NET dlls ... In doing my latest WebGL Build, I had the following DLLs included:

    Boo.Lang.dll
    UnityScript.Lang.dll
    UnityEngine.dll
    mscorlib.dll
    Vectrosity.dll
    Mono.Security.dll
    System.Core.dll
    System.dll
    Assembly-CSharp-firstpass.dll
    Assembly-UnityScript-firstpass.dll
    Assembly-UnityScript.dll

    All of these together comprise about 81% of the build size (or about 4.1MB).

    Other than the Vectrocity.dll, I have no idea where these other DLLs are coming from or if I even really need them. Obviously some or all of the DLLs are required by Unity.

    Can you shed any light on this? Are some of these potentially problematic where memory size is concerned?

    For what its worth, all of my code is either C# or UnityScript (not sure where the need for Boo.Lang.dll is coming from)

    Thanks
     
    wbl1, Jun 4, 2015
    #6