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. _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
