On Wed, Mar 9, 2016 at 12:08 PM, René J.V. <rjvber...@gmail.com> wrote: > On Wednesday March 09 2016 08:41:56 Eric A. Borisch wrote: > >> FWIW, if compressed with HFS+ compression (afsctool with -f -6 -s 50 >> options, for reference), llvm-3.7 and clang-3.7 combined take 756MB rather >> than 3.4+ GB. > > I use a patched portimage.tcl that uses bsdtar from port:libarchive which > supports the --hfsCompression argument. I know the gain can be significant, > but never calculated it precisely. > > Regardless, >700Mb is still a far cry from (>10x) what I've seen cited for > just libclang. > >> One potential port that comes to mind would be cling >> as dependency of (= part of) ROOT 6, but I would imagine that it would >> need quite a bit of effort before ROOT and/or cling could simply >> depend on "libclang" > > Looks like "Cling is an interactive C++ interpreter, built on the top of LLVM > and Clang libraries" but is built inside *a* llvm+clang tree hosted by the > CERN and having a dedicated branch called cling-patches. That does seem to > make it a bit unlikely that one day cling could build against a stock > libclang ... > > Another potential candidate for which I already have a personal port is > clazy: https://www.kdab.com/use-static-analysis-improve-performance/ > > > About libLLVM: I'm told that libclang's dependency on libLLVM happens "when > you build enable shared libraries for libLLVM. This is not good for > performance, and should not be done when you want to create a libclang for > redistribution purposes." > > I've heard that before, and wonder if it's the reason clang-mp-x.y has always > been up to 2x slower than equivalent Apple builds (and not just for me).
Have you checked to make sure that the installed llvm packages aren't built as the +assertions variant? The use of assertions will have a large performance impact and isn't recommended for the llvm releases. The llvm-3.8 Portfile was defaulting to the +assertions variant until 4 days back and only switched that off upon the official release of 3.8.0. However, port isn't smart enough to honor that change for previous installations of llvm-3.8 so the +assertions variant will remain on your volume until you explicitly install the new -assertions default variant. The MacPorts clang-3.8 build (without assertions) seems about 10% slower than the same under the fink packaging of llvm38/clang38 but the fink packaging uses the default -O3 optimization whereas MacPorts resets the build to use -Os instead, Also, keep in mind that each release of clang has been getting slower over time as discussed in this thread... http://lists.llvm.org/pipermail/llvm-dev/2016-March/096488.html > > Is there a reason the LLVM ports build a shared libLLVM? > > R. > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev