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

Reply via email to