Once 755145 is fixed, we should be able to reenable ccache on OS X. The question is finding out if it is profitable. How should we benchmark this?

I just noticed I posted the benchmark to the wrong bug :-) What I got locally on my laptop with a 10GB cache was ccache build 1 with empty cache real 36m40.916s user 99m18.844s sys 12m22.869s ccache build 2 empty objdir, but full cache real 11m53.582s user 9m9.587s sys 3m22.222s no ccache real 32m11.518s user 90m58.849s sys 8m43.691s

We should be able to at least compare a build without ccache and the initial ccache build at: https://tbpl.mozilla.org/?tree=Try&pusher=respindola@mozilla.com If the regression is not too terrible and we have some form of monitoring we can push it and keep and eye at the try build times.

The times differences are: opt: 78 m -> 87 m 32 bit debug: 62 m -> 66 m 64 bit debug: 56 m -> 61 m So we do need some numbers showing that we get a good cache hit ratio to justify this. Do we log the try build times somewhere?

It might be able to find the build times by looking at http://builddata.pub.build.mozilla.org/buildjson but I am not sure if I am doing something wrong, but i am getting suspiciously fast times for try on http://builddata.pub.build.mozilla.org/buildjson/builds-2012-07-19.js.gz: > f=file('builds-2012-07-19.js') > import json > x=json.load(f) > y=x['builds'] > z=[a for a in y if a['properties']['branch']=='try'] > t=[a['endtime'] - a['starttime'] for a in z] > print (float(sum(t))/len(t))/60 29.803630363

I am still getting a 24 minute average on os x :-( #!/usr/bin/python import json f = file('builds-2012-07-19.js') data = json.load(f) builds = data['builds'] try_builds = [x for x in builds if x['properties']['branch']=='try'] successful_try_builds = [x for x in try_builds if x['result'] == 0] os_x_names = set(['macosx', 'macosx64', 'lion', 'macosx-debug', 'macosx64-debug', 'snowleopard', 'leopard']) successful_os_x_try_builds = [x for x in successful_try_builds if x['properties']['platform'] in os_x_names] times = [x['endtime'] - x['starttime'] for x in successful_os_x_try_builds] print (float(sum(times))/len(times))/60

Catlee found out that I was not filtering test runs. The attached simple script prints a more reasonable time of 68.5 minutes.

I checked it in as d00e2e2b5e22. I will keep an eye in our build times.

The hit rate looks good: https://tbpl.mozilla.org/php/getParsedLog.php?id=13737534&tree=Try&full=1 cache directory /builds/ccache cache hit (direct) 4683 cache hit (preprocessed) 101 cache miss 23 called for link 31 called for preprocessing 8 compile failed 1 preprocessor error 1 bad compiler arguments 1 unsupported source language 3 autoconf compile/link 24 unsupported compiler option 120 no input file 7 files in cache 32914 cache size 1.4 Gbytes max cache size 10.0 Gbytes

Build times look good too. I will check again tomorrow to get Mondays' data, but so far: $ ./filter-try.py builds-2012-07-17.js 32 bit debug: 68.4441314554 64 bit debug: 62.6162037037 opt : 99.987037037 $ ./filter-try.py builds-2012-07-18.js 32 bit debug: 66.5768888889 64 bit debug: 62.9376712329 opt : 96.0635555556 $ ./filter-try.py builds-2012-07-19.js 32 bit debug: 61.9634538153 64 bit debug: 58.6325102881 opt : 85.5196202532 $ ./filter-try.py builds-2012-07-20.js 32 bit debug: 60.3921052632 64 bit debug: 56.7241545894 opt : 82.0085271318 $ ./filter-try.py builds-2012-07-21.js 32 bit debug: 61.0666666667 64 bit debug: 56.3333333333 opt : 81.3152777778 $ ./filter-try.py builds-2012-07-22.js 32 bit debug: 53.1622222222 64 bit debug: 51.062037037 opt : 68.3948717949

It seems to have regressed a bit, but it is still a win: $ ./filter-try.py builds-2012-07-23.js 32 bit debug: 59.9995726496 64 bit debug: 53.8658914729 opt : 76.5390070922 $ ./filter-try.py builds-2012-07-24.js 32 bit debug: 60.2742690058 64 bit debug: 54.188172043 opt : 78.5737288136