“Joel E. Denny via cfe-dev” <email@example.com> writes:
Do other Clang developers find BUILD_SHARED_LIBS=True useful? Do you
see the above failures? Should there be a bot to test that build
I don’t use BUILD_SHARED_LIBS=True
One point I’d like to understand is why more people don’t use it. Were you not aware of it, or is it just not beneficial enough to you? I was very happy to reduce a nearly 4-minute rebuild after a minor change to ~31 sec. Especially when I have to do that repeatedly, that time difference can determine whether I decide to switch contexts or stay focused.
How much of that rebuild time is actually link time? I’d guess most.
Yes. Even more so because I forgot I have ccache enabled.
What linker are you using? ld64, lld and gold are all much faster than bfd, so the performance implications may be smaller to other people.
I just tried LLVM_USE_LINKER=gold and then lld, and lld gave me a better incremental build time, so I’ll stick with it.
The aforementioned ~4 min shrank to ~35s. However, BUILD_SHARED_LIBS=True shrank that to 3s!
Continuing to use lld, when I disable ccache (or make a change ccache hasn’t seen), it’s ~40s and BUILD_SHARED_LIBS=True shrinks it to ~13s.
The gap is certainly closing, but BUILD_SHARED_LIBS=True still seems appealing.
BUILD_SHARED_LIBS has a significant impact on execution performance of the final binaries, which impacts test execution speed. So if you aren’t struggling with link time, it can be overall better to generate faster loading binaries for the test suite.
Indeed, ninja check-clang grows from ~10 min to ~20 min when I use BUILD_SHARED_LIBS=True. Either way, I’d switch contexts instead of waiting, so my development time wouldn’t necessarily grow with the latter.
Nevertheless, whether to use BUILD_SHARED_LIBS=True is definitely a harder choice to make now.
There are a lot of tradeoffs on performance, but I’ve strongly advocated that BUILD_SHARED_LIBS should never be used when building distributions for performance reasons, which means it is only really supported as a developer workflow.
Seems fine to me except that, if it is supported as a developer workflow, the broken tests are a problem.
Additionally BUILD_SHARED_LIBS is problematic with some of LLVM’s design patterns, like cl::opt’s global registration, which can deter its usefulness.
Could you explain a little more, or point to a previous discussion?
Hope this helps explain why it is less widely used than you might have anticipated.