Suggestion: add ALLOW_MEMORY_GROWTH flag to editor player settings

Unity Engine
1

If I understand it correctly, using

PlayerSettings.SetPropertyString("emscriptenArgs",
        "-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.

1 Like
Cannot Enlarge Memory Arrays Browser error
2

where do you add this?

3

The code? You would place it in an editor script. Possibly, you could put it in an editor script to build your player

PlayerSettings.SetPropertyString("emscriptenArgs", "-s ALLOW_MEMORY_GROWTH=1", BuildTargetGroup.WebGL);
BuildPipeline.BuildPlayer(levels, buildPath, target, options);
1 Like
4

Interesting… what browser(s) did you test this on? What was your mem set to before the increase?

5

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

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

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

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

Thanks for that insight Jonas. Its helpful even when its not conclusive.

10

That makes sense.
So how about adding some documentation about it, then?

11

I dunno, I don’t see much of a point in adding documentation about things we don’t do?