I'll check that and create a new topic here, since it's only loosely related. Thank you all so much, really helped me a lot!
Am Freitag, 29. Mai 2015 18:10:27 UTC+2 schrieb Alon Zakai: > > That is surprising. Do you see anything odd in the chrome profiler when > you run it on the optimized build? Or perhaps when comparing profiling > results on an optimized to an unoptimized build? (best to profile on builds > with --profiling) > > - Alon > > > On Fri, May 29, 2015 at 4:59 AM, Björn K. <[email protected] > <javascript:>> wrote: > >> @Bruce Mitchener: Thank you sooo much for seeing that damn bug! Once this >> has been fixed, compilation went smoothly with any optimization! >> >> The JavaScript size went down from 3.5 MB to 680 KB with optimization >> level -O3. Performance increased on Firefox browser by a factor of 2 >> compated to -O0. Both are great results! >> >> One thing I wonder about: Using Chrome, the O0-build is the fastest (with >> very similar speed compared to Firefox) but when using -O3, Firefox gets >> about 30% faster whereas Chrome takes 100% _more_ time. Are there any >> optimization strategies to enable Chrome getting faster? >> >> Best regards, >> Björn >> >> >> Am Donnerstag, 28. Mai 2015 15:45:07 UTC+2 schrieb Bruce Mitchener: >>> >>> I don't think this has anything to do with threads after looking at it a >>> bit after dinner. >>> >>> The call stack looks clearly incorrect ... there's no reason for >>> emit_message out of libjpeg to be calling __ZN10__cxxabiv112_GLOBAL__N_ >>> 19destruct_EPv >>> >>> If we look at the code in emit_message in JS, the line involved is: >>> >>> FUNCTION_TABLE_vi[HEAP32[(HEAP32[i6 >> 2] | 0) + 8 >> 2] & >>> 63](HEAP32[i4 >> 2] | 0); >>> >>> The line from C is: >>> >>> (*err->output_message) (cinfo); >>> >>> I really don't think this should be invoking what it is. >>> >>> So ... looking a bit further, we see this function in your C++ code: >>> >>> void DecodeImage::prepare(int sizeOfData, emscripten::val callback) >>> { >>> // create and assign libjpegs internal data structure >>> struct jpeg_error_mgr jerr; >>> struct jpeg_decompress_struct cinfo; >>> this->cinfo = cinfo; >>> this->sizeOfData = sizeOfData; >>> >>> // Allocate Memory >>> this->imageData = (uint8_t*) malloc(this->sizeOfData); >>> callback(emscripten::memory_view<uint8_t>(this->sizeOfData, >>> this->imageData)); >>> >>> // Allocate and initialize JPEG decompression object >>> this->cinfo.err = jpeg_std_error(&jerr); >>> >>> // Now we can initialize the JPEG decompression object. >>> jpeg_create_decompress(&this->cinfo); >>> >>> // Specify data source >>> jpeg_mem_src(&this->cinfo, (unsigned char*)(this->imageData), >>> this->sizeOfData); >>> } >>> >>> That's creating jerr on the stack, saving a pointer to it, and then >>> exiting, leaving that pointer invalid. You need to fix your memory >>> allocation and then all will probably be well. >>> >>> Cheers, >>> >>> - Bruce >>> >>> >>> -- >> 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.
