Search Unity

Suggestion: add ALLOW_MEMORY_GROWTH flag to editor player settings

Discussion in 'Web' started by prestonmatterport, Jul 29, 2015.

  1. prestonmatterport

    prestonmatterport

    Joined:
    May 7, 2015
    Posts:
    28
    If I understand it correctly, using
    Code (CSharp):
    1. PlayerSettings.SetPropertyString("emscriptenArgs",
    2.         "-s ALLOW_MEMORY_GROWTH=1", BuildTargetGroup.WebGL);
    allows the WebGL player to dynamically change the size of the memory buffer.

    For me (and probably many others out there), there is not much of a slowdown caused by using this flag, and stability is more important to me than speed.
     
    EdRowlett-Barbu likes this.
  2. mnml_

    mnml_

    Joined:
    Jun 17, 2015
    Posts:
    44
    where do you add this?
     
  3. prestonmatterport

    prestonmatterport

    Joined:
    May 7, 2015
    Posts:
    28
    The code? You would place it in an editor script. Possibly, you could put it in an editor script to build your player

    Code (CSharp):
    1. PlayerSettings.SetPropertyString("emscriptenArgs", "-s ALLOW_MEMORY_GROWTH=1", BuildTargetGroup.WebGL);
    2. BuildPipeline.BuildPlayer(levels, buildPath, target, options);
     
    Davud04 likes this.
  4. levwsr

    levwsr

    Joined:
    Jul 23, 2012
    Posts:
    68
    Interesting.. what browser(s) did you test this on? What was your mem set to before the increase?
     
  5. prestonmatterport

    prestonmatterport

    Joined:
    May 7, 2015
    Posts:
    28
    So, FYI, using this flag will disable asm.js optimizations. This supposedly makes your player much slower. I have not seen much slowness, but your results may vary.

    I tested it on Chrome. I set the memory to 256MB, although you could use any number that doesn't exceed the browser's capacity.
     
  6. levwsr

    levwsr

    Joined:
    Jul 23, 2012
    Posts:
    68
    That sounds.. devastating. Our game codebase is so large, that it is unstable in browsers unless optimize is on - we had to give up ever making debug builds.
     
  7. muzzythom

    muzzythom

    Joined:
    Dec 1, 2014
    Posts:
    17
    It will disable some optimizations in chrome. Not all, I think. Also it doesn't disable optimizations in firefox.

    I haven't seen any negative effects from using this, however it might be worth noting that if you can't allocate the larger memory size initially, odds are you can't grow to that size, since that requires even more memory be available when you try to grow.
     
  8. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    We have been considering using this flag, but so far decided not to to because:

    1. As written here, doing so would disable some optimizations in Chrome. We have yet to do some real benchmarking on this impact of this.

    2. I'd expect that using this might actually make memory issues worth. If you have reached a point where the Unity Heap is to small to fit all the required memory, and it needs to grow, then the browser would have to allocate a bigger heap, and copy everything over from the old heap, and then deallocate the old heap. By doing so, it needs memory for both the new and the old heap at the same time (until it finished the copy), thus requiring more total memory. So the memory usage would be higher then when using a predetermined fixed memory size.

    It would be more convenient for the developer, though.
     
  9. levwsr

    levwsr

    Joined:
    Jul 23, 2012
    Posts:
    68
    Thanks for that insight Jonas. Its helpful even when its not conclusive.
     
  10. prestonmatterport

    prestonmatterport

    Joined:
    May 7, 2015
    Posts:
    28
    That makes sense.
    So how about adding some documentation about it, then?
     
  11. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    I dunno, I don't see much of a point in adding documentation about things we don't do?