PS: may be it's interesting to know that linking these demo as native exes in clang (for instance in Xcode) is basically instant, so may be the actual llvm-linker time is so small in this case that the optimization doesn't matter much).
Am Mittwoch, 19. August 2015 16:35:12 UTC+2 schrieb Floh: > > Hmm despite my best efforts to skew the results I don't see much > difference ;) > > The biggest demo (TurboBadgerDemo) takes around 17 seconds to link in > master, and around 16 seconds on incoming, all the other demos take much > less (around 5 seconds). > > I won't rule out that I made an error switching between incoming and > master (although I double-checked a few things, like making sure that the > right emcc from the right SDK path is used). > > Cheers, > -Floh. > > Am Mittwoch, 19. August 2015 11:50:13 UTC+2 schrieb Floh: >> >> "Subjectively yes", but I didn't measure the difference and since the >> demos are small the link step is only a couple seconds anyway :) >> >> I'll try to do a quick comparison with master. >> >> -Floh. >> >> Am Dienstag, 18. August 2015 22:46:46 UTC+2 schrieb Alon Zakai: >>> >>> Great, thanks! >>> >>> Did you notice any compilation speed improvements? >>> >>> On Tue, Aug 18, 2015 at 1:25 PM, Floh <[email protected]> wrote: >>> >>>> Tested with the Oryol demos and all looking good :) >>>> >>>> Cheers, >>>> -Floh >>>> >>>> >>>> Am Montag, 17. August 2015 22:46:05 UTC+2 schrieb Alon Zakai: >>>>> >>>>> The incoming branches now have an optimization which avoids llvm-link >>>>> when possible. This is kind of a hack, but looks like it's worth it - it >>>>> pushes linking into the opt call we do afterwards anyhow, which avoids >>>>> saving and then loading the entire module. On large codebases, this >>>>> matters >>>>> a lot it turns out, much more than I expected. >>>>> >>>>> I also optimizing llvm linking in some other ways (avoid a copy of the >>>>> first input), and disabled extra verifications in optimized builds. >>>>> >>>>> On incoming, I see a 30% speedup on Poppler and 35% on Unity, on -O2 >>>>> builds. >>>>> >>>>> This did change some toolchain code, please test and report bugs if >>>>> you find any. >>>>> >>>>> Side note, it looks like linking order matters a lot in llvm. It is >>>>> always better to have the larger file first in the link command, because >>>>> the llvm linker starts with the first module, then links the second into >>>>> it. So you want to write >>>>> >>>>> emcc bigger-bitcode.bc smaller-bitcode.bc >>>>> >>>>> both when linking them to bitcode and when compiling to JS. (Of >>>>> course, sometimes you can't change the link order, like when using .a >>>>> files >>>>> where the order matters.) >>>>> >>>>> - Alon >>>>> >>>>> -- >>>> 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.
