I would be surprised if there is a difference from 1.35, nothing there should have changed? Can you bisect to see where the issue begins? Or provide a minimal but complete testcase including measurement and compilation flags, so we can test?
Comparing to native C++ though, there are expected differences, mainly since we don't have virtual memory. Reallocating memory natively can sometimes map pages and not do an actual copy, but if we need to move things, we always copy. Another issue is that in memory growth mode, allocating or reserving memory might cause memory to grow, which can be slow. On Tue, May 17, 2016 at 4:23 AM, 'Sören König' via emscripten-discuss < [email protected]> wrote: > (re)allocating a large stl vector using the constructor, resize or reserve > calls like > > std::vector<unsigned char> abc(1920000); > > or > > std::vector<unsigned char> abc; > abc.reserve(1920000); > > seems to be extremely slow in comparison to a simple malloc with exactly > the same size in emscripten 1.35. > > Coming from a native C++ world, I would expect similar timing result as > for malloc. > Are there any special optimization flags to enable? Or is this a browser > specific issue? > > > > > > > > > > > > -- > 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.
