Thanks for your reply Alon. Unfortunately, I am inheriting some legacy
code which I do not hope to touch, so is it possible to still keep the
code that references a vector intact e.g.:
#include <vector>
int main()
{
std::vector<int> a;
a.push_back(5);
}
but force Emscripten to not link with STL (perhaps thru a compiler
setting) and at the same time, put in my own Vector implementation?
On Thu, Jul 24, 2014 at 2:45 AM, Alon Zakai <[email protected]> wrote:
> If you use STL things and the linker sees unresolved symbols, then STL will
> be linked for you. If you implement yourself parts of STL, then there will
> be no unresolved symbols and it should not include STL.
>
> - Alon
>
>
>
> On Wed, Jul 23, 2014 at 3:19 AM, Kevin Cheung <[email protected]> wrote:
>>
>> 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.
>
>
> --
> 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.
