port:libclang (and libLLVM)

[Jack Howarth]

On Wed, Mar 9, 2016 at 8:43 PM, Jack Howarth
<howarth.at.macports at gmail.com> wrote:
> On Wed, Mar 9, 2016 at 6:36 PM, René J.V. <rjvbertin at gmail.com> wrote:
>> On Wednesday March 09 2016 18:00:07 Jack Howarth wrote:
>>
>>> 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
>>
>> Oh yes. With that variant active the performance hit is much worse from what I recall, so I've been making a point of it only to install release versions, without assertions active.
>>
>>> 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
>>
>> I wouldn't call the user who doesn't notice that all of a sudden a clang/llvm upgrade takes hours because built from source particularly bright either ;)
>>
>>> 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,
>>
>> Frankly I'd be surprised if that leads to a 10% performance difference!
>
> Why? My understanding is that the optimizations for -Os are equivalent
> to -O2 with the emphasis on size reduction. The additional
> optimizations from -O2 to -O3 would seem sufficient to produce a 10%
> execution optimization, no?

The only other difference I see between the fink and MacPorts
packaging is the use of -DLLVM_ENABLE_RTTI=ON in MacPorts. My
understanding is that these additional virtual functions can introduce
overhead in c++.

>
>>
>>> Also, keep in mind that each release of clang has been getting slower
>>> over time as discussed in this thread...
>>
>> Indeed, which is why I compared comparable versions in the past; my "up to 50%" estimate is based on that.
>>
>>> > Is there a reason the LLVM ports build a shared libLLVM?
>>
>> ?
>>
>> R.