On Wed, Nov 26, 2008 at 2:42 PM, Argiris Kirtzidis <[EMAIL PROTECTED]> wrote: > Hi Daniel, > > Daniel Dunbar wrote: >> >> >From a performance monitoring perspective, this commit would have been >> easier to inspect if broken down further. No idea how easy that would >> have been, just a comment. >> > > Sorry for the huge commit. > It's really awesome that you track performance regressions! Are there still > issues after your commit in r60063 ?
Roughly speaking, yes; we still have lost something on the order of 10% on Cocoa.h in the past 4-6 weeks. My patch turned out to be misleading, the performance improvement I saw when I was timing disappeared when I rolled my tree forward (the most notable commit that came in in the meantime was 60057). Unfortunately, it appears to be a general trait that clang's performance is very susceptible to "innocuous" changes, most likely due to changes in caching or code alignment. Here is a current snapshot of the data I have been collecting: http://t1.minormatter.com/~ddunbar/utime-syntax-rev-2.pdf which shows just how much our performance fluctuates regularly. In fact, if I sort the commits by how much they impact performance, a surprising number of the most significant ones involves changes to LLVM which should have no impact on clang other than to force code to move. This has made it difficult to try and look for individual commits which degraded performance. One possible solution to this problem is to look at metrics other than time, for example code size and simulated instructions counts, which should be less influenced by non-local changes yet still roughly correlate with performance over the long term. I have started collecting data for this but haven't yet built any visualization of it. Thanks for the other commits & tweaks! - Daniel _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
