Wow I was totally not aware of the --memoryprofiler and --cpuprofiler flags, that's awesome! (I wish native build environment had something like this).
Am Montag, 1. August 2016 12:14:27 UTC+2 schrieb jj: > > If it might be useful, Emscripten provides a built-in memory profiling > feature that allows you to get an overview of the application's memory > consumption. Use the linker flag `--memoryprofiler` to enable that for your > build. See here for an example: > http://clb.demon.fi/emcc/cpu_mem_profiler/hello_world_gles_cpu_mem_profiled.html > > (that one has also --cpuprofiler in it, which is the top block, > memoryprofiler is at the bottom). > > 2016-07-28 23:06 GMT+03:00 Alon Zakai <[email protected] <javascript:>>: > >> To set total memory at runtime, you can do the same in a worker as in the >> main thread, set Module.TOTAL_MEMORY. >> >> asm.js officially stopped supporting memory growth. It should be the same >> on all browsers - none should be doing asm.js opts when memory growth is >> used. Definitely chrome and firefox do not. (In WebAssembly we'll have >> memory growth fully optimized, so people are focusing on that.) >> >> On Thu, Jul 28, 2016 at 8:28 AM, 'Peter Nemeth' via emscripten-discuss < >> [email protected] <javascript:>> wrote: >> >>> Right, those were my thoughts as well. >>> >>> Meanwhile I've bumped into the limitations of large ArrayBuffers in 32 >>> bit buffers, i.e. even if I work out the required memory it can end up >>> being quite high which is not possible on 32 bit browsers. Based on my >>> tests the limits is around 0.5-1GB depending on the browser. Found some >>> relevant discussion here >>> https://bugzilla.mozilla.org/show_bug.cgi?id=927182 and here >>> https://bugzilla.mozilla.org/show_bug.cgi?id=965880 about virtual >>> address space, committed memory, etc. Also found this 32 bit related >>> initiative in Firefox: >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1277066 >>> >>> A few more questions: >>> - how to set the TOTAL_MEMORY for a worker at runtime? >>> - is it known in which browser does ALLOW_MEMORY_GROWTH disable asm.js? >>> I know Chrome has an issue ( >>> https://bugs.chromium.org/p/v8/issues/detail?id=3907) but what about >>> other? >>> - any experience with using WORKERFS in a 32 bit browser? How do Blobs >>> relate to the virtual address space, i.e. do browsers remove them from the >>> address space when not in use or on tight memory? >>> >>> Thanks >>> >>> 2016. július 27., szerda 19:19:11 UTC+2 időpontban Alon Zakai a >>> következőt írta: >>>> >>>> Emscripten allocates an ArrayBuffer for memory. In principle, browsers >>>> call internally allocate it using calloc(), which would let most OSes only >>>> create physical pages when actually needed. However, in practice, some >>>> browsers have optimizations for the location of asm.js typed arrays, which >>>> can remove some bounds checks, but it does limit the effectiveness of >>>> calloc(). >>>> >>>> In general, it is best to assume that TOTAL_MEMORY will use physical >>>> memory immediately. Memory growth is an option to use memory more >>>> flexibly, >>>> but as you said, it has perf limittaions. >>>> >>>> On Wed, Jul 27, 2016 at 8:11 AM, 'Peter Nemeth' via emscripten-discuss >>>> <[email protected]> wrote: >>>> >>>>> I was digging this a bit more and it's not the browser but the OS. >>>>> What Activity Monitor / Task Manager shows is the resident memory. The >>>>> about:memory page of Firefox clearly shows everything related (resident, >>>>> vsize, js engine, asm.js, ...). >>>>> >>>>> The questions still apply though. Can I rely on this in practice >>>>> (given the browser is 64 bit, 32 bit browsers are worse from this point)? >>>>> Tips for production? >>>>> >>>>> >>>>> 2016. július 26., kedd 15:10:27 UTC+2 időpontban Peter Nemeth a >>>>> következőt írta: >>>>>> >>>>>> I'm trying to find out the best memory configuration for our >>>>>> application. It's using a lot of user generated content so we cannot be >>>>>> sure about the required TOTAL_MEMORY at compile time. We could calculate >>>>>> that upfront on the backend and set in the Module before loading but I >>>>>> would like to avoid that if possible. Also don't want to enable memory >>>>>> growth because of its performance drawbacks. After checking some >>>>>> browsers >>>>>> with a simple test it seems like they are smart enough not to allocate >>>>>> the >>>>>> whole buffer in C++ regardless the requested size of the ArrayBuffer. Do >>>>>> you know if this works in practice? How is Emscripten handling the HEAP >>>>>> stack-, and heap-wise? Where are they located in the HEAP? Any tips from >>>>>> production applications how they solve memory configuration? >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "emscripten-discuss" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] >>> <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
