Thanks for the link, I will check out tools/find_bigfuncs.py when I have the time.
Just to bring out my previous question in case it got lost in the thread: I am currently trying to port some legacy code which uses only a few STL containers such as vectors and maps. Is there a way for me to not build STL with the generated JS and replace the vector and map classes with my own implementation without touching the legacy code? Such as thru DEFAULT_LIBRARY_FUNCS_TO_INCLUDE for e.g.? On Wed, Jul 23, 2014 at 12:25 AM, Jukka Jylänki <[email protected]> wrote: > Just for cross-referencing, > https://github.com/kripken/emscripten/issues/2527 would help immensely here > in tracking what causes big output sizes and why, although we don't > currently have anyone working on such a tool. > > > 2014-07-22 18:43 GMT+03:00 Floh <[email protected]>: > >> Hmm, LTO might also increase code size because it inlines more stuff (but >> I found that this inlining is quite important for performance), on the other >> hand it should a do pretty aggressive dead-code elimination. >> >> Not sure if this helps in your case, but I'm currently compiling like >> this: >> >> Object files: -Oz >> Linker Stage : -Oz --llvm-lto 3 --closure 1 >> >> (plus some other stuff which shouldn't be relevant for size or >> performance). >> >> I've used -O2 before, and may decide to switch back depending on >> performance tests I'm doing from time to time. >> >> >> Am Dienstag, 22. Juli 2014 12:55:01 UTC+2 schrieb awt: >>> >>> Thanks Floh and Alon for your detailed replies. Really appreciate it. >>> >>> I tried to use both --llvm-opts and --llvm-lto but interestingly, the >>> size of the JS increased from 2202kb to 2328kb. These are my build >>> parameters: >>> >>> emcc vector.cpp -o hello.html --llvm-opts 3 --llvm-lto 1 >>> >>> Is there something wrong with the way that I am using the parameters >>> above? I could use -Oz and -profiling because that would still give me >>> debuggable code but just want to clarify if the -Oz optimization already >>> includes --llvm-lto? >>> >>> I am currently trying to port some legacy code which uses a only few STL >>> containers such as vectors and maps. Is there a way for me to not build STL >>> with the generated JS and replace the vector and map classes with my own >>> implementation without touching the legacy code? Such as thru >>> DEFAULT_LIBRARY_FUNCS_TO_INCLUDE for e.g.? >>> >>> >>> >>> On Tuesday, July 22, 2014 6:51:53 AM UTC+8, Alon Zakai wrote: >>>> >>>> std::vector causes emscripten to pull in libc++, a full implementation >>>> of the C++ standard library. It then tries to strip out code it can prove >>>> is >>>> not used, but in practice just including std::vector is enough to keep >>>> quite >>>> a bit alive. std::iostream is worse. >>>> >>>> Building with LTO may decrease the size somewhat (--llvm-lto 1). >>>> >>>> - Alon >>>> >>>> >>>> >>>> On Mon, Jul 21, 2014 at 2:59 AM, awt <[email protected]> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I wrote 2 simple programs to compare the size of the Javascript files >>>>> generated in unoptimized mode for both array and vector: >>>>> >>>>> 1. Array version: >>>>> >>>>> int main() >>>>> { >>>>> int arr1[2000]; >>>>> add(arr1); >>>>> return 0; >>>>> } >>>>> >>>>> void add(int arr[]) >>>>> { >>>>> for(int i=0;i<2000;i++) >>>>> { >>>>> arr[i]=i; >>>>> } >>>>> } >>>>> >>>>> 2. Vector version: >>>>> >>>>> int main() >>>>> { >>>>> vector<int> v1; >>>>> add(v1); >>>>> return 0; >>>>> } >>>>> >>>>> void add(vector<int>& v) >>>>> { >>>>> for(int i=0;i<2000;i++) >>>>> { >>>>> v.push_back(i); >>>>> } >>>>> } >>>>> >>>>> I was quite surprised that the size of the JS file generated for the >>>>> array is only 203KB but the vector version took up 2393KB. Are there >>>>> built-in optimizations for STL classes in Emscripten that I could leverage >>>>> on to shrink the file size or do I have to implement my own vector >>>>> classes? >>>>> Any suggestions would be much appreciated. Thanks in advance. >>>>> >>>>> -- >>>>> 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 a topic in the > Google Groups "emscripten-discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/emscripten-discuss/WTHJTJcsWPA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. -- In His grace, Kevin Cheung -- 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.
