Hello,
We are working with Unity version 5.3.8p2 and are looking to upgrade to 2018.1 due to WebAssembly, but are not sure if it is worth the effort for us or not.
We have been testing Unity 2018.1 to make sure that things work as expected, but wished to test it with something like the Unity Performance Benchmark by Jonas: Unity WebGL Benchmarks (which unfortunately doesn’t seem to be working at all for us in chrome currently? https://aboutmybrowser.com/scLOZ0S6 , works in firefox however.)
For us it would be an enormous help if we could download a project like such in order to test with the emscriptenArgs “-s ALLOW_MEMORY_GROWTH=1”, and without them.
The benchmark needs to be rebuilt (calls a depreciated audio function that chrome has removed). In general though yes wasm is a big win. @Marco-Trivellato probably has a better idea of the ramifications of using ALLOW_MEMORY_GROWTH (enabled by default with 2018.2 for wasm iirc?).
ALLOW_MEMORY_GROWTH also seems to disable some optimizations according to the console - is this anything that will visibly affect performance? We would still really appreciate the physical project to experiment on, if that would be available!
Heap growth with WebAssembly will only work in 2018.2+. It may work in previous versions if you pass “-s ALLOW_MEMORY_GROWTH=1” but we don’t support it.
We are not planning to support heap growth with asm.js at all.
Alrighty!
Thank you for your replies.
We have done some tests in 2018.1, where we enabled memory growth when building for WebAssembly. Is there any reason as to why this wouldn’t work? Is 2018.2 the minimum requirement to have this working in WebAssembly at all?
We’ve tested setting the size to 32MB, and gotten a simple project to grow beyond that by allocating more memory than 32.
It should work in 2018.1 if you enable it on your own but it becomes complicated to manage if you need to ship both asm.js and Wasm, for the reason that you don’t want that flag with asm.js
Adding official support in Unity is tricky because 2018.1 already shipped and this is technically a new feature. Having said that, if enough people ask for it, we could evaluate whether it is feasible to backport from 2018.2.
My team has had the ALLOW_MEMORY_GROWTH flag enabled since 2017.3 with no performance or other issues in wasm. It’ll nicely initialise at 128mb and grow at 2x size until 1024mb, then further growth happens in 100mb increments until the limit of 2032mb is reached.
However I wouldn’t recommend it for asm.js either :).
One thing we have been considering is the option to set a maximum heap size, so that the heap cannot grow above that threshold. I think this would be useful to keep memory under control, especially during development. @ThomasKogama@JJJohan based on your experience, is that something that would be useful for your use-case?