I’m currently trying to port a large project from WebPlayer to WebGL, using Unity 5.0.1f1.
My development machine is a 3.4GHz Intel i7 with 24Gb RAM running Windows 8 64-bit.
I’ve got it to a state where a non-development build runs in Firefox (32-bit), with memory size set to 1024Mb. A development build will give OOM errors. For both builds, I used optimisation level “Slow”.
However, it won’t run in Chrome (32-bit), and suggests that I reduce the WebGL memory size. 512Mb gives the same result. 256Mb runs, but then fails to allocate memory in the game.
In another thread, jonas echterhoff, said:
Why is 32-bit Chrome singled out as problematic?
FWIW, I have tried running in Chrome with only one tab, and no other programs open, but this did not change the outcome.
I have also tried 64-bit Chrome, but it failed even sooner (didn’t seem memory related as far as I could tell).
I have also tried “Build and Run” with auto attaching the profiler, but the profiler seemed not to attach, and the brower (Firefox) was not present in the dropdown.
Any help would be much appreciated!
Colin
Edit: Just tried “Fastest” optimisation level and got error: “Uncaught RangeError: Invalid typed array length” on first line of the buillt JS file.
Chrome’s JavaScript engine (V8) does a lot of small allocations when parsing large code bases, meaning that Chrome will need a lot of memory and leave memory space fragmented just to parse your code. This may result in not having enough memory left to allocate a big continuous block of memory to run the game.
Firefox uses asm.js to run the code, which is better in memory consumption.
The only thing you can do to avoid this is to make your code size as small as possible. Enable stripping, disable exceptions, make a “Fast” non-development build.
Profiling WebGL on Windows is broken in 5.0. This will be fixed in 5.1.
Just some extra info before I look into your suggestions…
I got it running in Chrome, with memory size set to 256Mb, by stripping out 2 thirds of the game content (this is not a viable solution btw). However on repeated F5 refreshes of the page, it mostly alternated between the memory error popup and a Chrome “Aw, snap!” error page (screenshots of both attached), but occasionally did actually run again. Can you explain this inconsistency? Is it to do with randomness of the fragmentation of memory by Chrome you mentioned?
Yes, errors when refreshing are usually related to memory fragmentation. In a clean run, your tab has plenty of free memory, but once you refresh, you have allocations all over the place, so you no longer have large free continuous blocks of memory as needed for the game to run. The first error happens when Unity fails trying to allocate it’s heap (a block of memory of the size specified in PlayerSettings). The “Oh Snap” crash is typical of Chrome internally running out of memory trying to parse the JS code.
at jsStackTrace (blob:http%3A//xxx.com/c9e9a260-215c-4697-be84-112811206b31:1057:12)
at stackTrace (blob:http%3A//xxx.com/c9e9a260-215c-4697-be84-112811206b31:1071:21)
at abort (blob:http%3A//xxx.com/c9e9a260-215c-4697-be84-112811206b31:3224984:43)
at nullFunc_ii (blob:http%3A//xxx.com/c9e9a260-215c-4697-be84-112811206b31:15243:2)
at Array.b132 (blob:http%3A//xxx.com/c9e9a260-215c-4697-be84-112811206b31:3219957:2)
at __ZN5Unity8Material14CreateMaterialER6Shaderib [Unity::Material::CreateMaterial(int&, bool)] (blob:http%3A//xxx.com/c9e9a260-215c-4697-be84-112811206b31:2095691:72)
at __ZN2UI20GetDefaultUIMaterialEv [UI::GetDefaultUIMaterial()] (blob:http%3A//xxx.com/c9e9a260-215c-4697-be84-112811206b31:2913678:7)
at Array.__Z38Canvas_CUSTOM_GetDefaultCanvasMaterialv [Canvas_CUSTOM_GetDefaultCanvasMaterial()] (blob:http%3A//xxx.com/c9e9a260-215c-4697-be84-112811206b31:3193657:54)
at Object.dynCall_i (blob:http%3A//xxx.com/c9e9a260-215c-4697-be84-112811206b31:3217164:35)
at invoke_i (blob:http%3A//xxx.com/c9e9a260-215c-4697-be84-112811206b31:16829:29)