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 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.

Reply via email to