Thanks - there is also --threadprofiler for -s USE_PTHREADS=1 builds, which gives a glimpse to the utilization rate of threads and if some threads might be deadlocked. The UI for each of these tools is developed mostly based on specific demand in the past for being able to debug some things (rather than a top down approach), so if there are some suggestions to improve, feature requests are welcome.
2016-08-01 19:40 GMT+03:00 Floh <[email protected]>: > 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]>: >> >>> 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]> 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]. >>>> 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. >>> >> >> -- > 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]. For more options, visit https://groups.google.com/d/optout.
