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.
