I looked at Bullet, which is a moderately sized library. It normally links in 8 seconds, and with -g4 it builds in 20 seconds. That's significantly slower, but it looks like almost all the extra time is from
1. We cannot use the fast native optimizer when emitting source maps 2. LLVM linking is slower on large files with debug info It sounds like the slowdowns you are seeing are much bigger, though, so perhaps you are seeing something else. The fact llvm-link takes 4 minutes is very strange. How fast is it *without* source maps? - Alon On Mon, Feb 2, 2015 at 11:35 PM, Alecazam <[email protected]> wrote: > Maybe this case isn't quite the same. No libraries, just straight source. > > -g4 on compile and link line. Take any moderate C++ 11 project and you > should see the same. > > compiles all spawned across multiple cores > first llvm-link at 8.64GB and 100% cpu, takes the longest ~ 4 minutes. > then opt at 4.5 GB and 100% cpu ~ 2 minutes. > python with 0.15GB at the end > > On Monday, February 2, 2015 at 5:13:49 PM UTC-8, Alon Zakai wrote: >> >> Is it when invoking the sourcemapper.js process? Or llvm-link? (process >> monitor can tell) >> >> Meanwhile in that issue, I think we know how to fix the correctness >> problem (although the fix may make it even slower, if we need to emit >> absolute paths). >> >> - Alon >> >> >> On Mon, Feb 2, 2015 at 3:55 PM, Alecazam <[email protected]> wrote: >> >>> > https://github.com/kripken/emscripten/issues/2970 >>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fkripken%2Femscripten%2Fissues%2F2970&sa=D&sntz=1&usg=AFQjCNFXnYTP-F1k44182kLHz4NkFRGetg> >>> > To be honest I haven't tried source maps on huge projects. It's very >>> possible there is a large inefficiency somewhere. Filing an issue with a >>> testcase would help investigate. >>> >>> I've seen that one before, and it's the same issue. Seems like he's >>> posted a test case already. >>> >>> I wouldn't say my tests are on huge projects. It's easy to see this in >>> the Activity Monitor when the linker goes off for minutes, and the GB just >>> keep increasing. I think we just passed 8GB with -g4 on non-debug builds. >>> This is the single biggest slowdown on links. It's not the optimizer. >>> If you remove -g4, the link times are down to 1 minute or less. With it, >>> they are more like 5-8 minutes on a quad core system with SSD. >>> >>> -- >>> 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.
