clang's build performance

[Ian Wadham]

Hi René,

On 07/07/2014, at 9:00 PM, René J.V. Bertin wrote:
> On Jul 07, 2014, at 12:39, Ian Wadham wrote:
> 
> Now why did I misread and wonder why Apple would have a Real Men column on a site called Activity Monitor? :)))

LOL.  Don't know why you misread that, but "to the pure all things are pure"… :-)

>> well enough almost all of the time.  However, sometimes it expands
>> seemingly without limit, both in wall clock time and memory space (as
>> reported by the Real Mem column of Apple's Activity Monitor).  This
> 
> I had this with clang-3.3 (less with 3.4) building 1 particular file of Calligra, which would take about an hour in which virtual memory peaked at nearly 20Gb (not it was probably much less than that when the process stalled). Very reproducible, but only on OS X 10.6 . Same, CPU usage was extremely low for such a hogging process, but that can simply be because swapping activity is not imputed to the process it's done for?
> 
>> Could episodes like this be affecting Clang performance measurements?
> 
> I think not, because as you say those kind of episodes have low CPU usage. So they'd also decrease the average/overall CPU usage reported after the build process completes, and that's not the case.

In my earlier email, I used the word "thrashing" (as described in
http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29).

If Clang can indeed get into thrashing mode, the total CPU time, over
a long wall-clock time, could well be larger than if the process had
unlimited memory.  That is a characteristic of thrashing.  CPU time gets
wasted on paging operations, instead of actual work.

In the Kate case, I think Clang is actually linking, not compiling, because
the build log goes to 100% quite quickly and then runs into a brick wall.
But I have no idea why linking Kate should be a problem for Clang.

Cheers, Ian W.