Perhaps useful to you: http://neugierig.org/software/chromium/bloat/
On Fri, Mar 22, 2013 at 12:06 PM, Elliott Sprehn <[email protected]> wrote: > I'd be really interesting to see what patches are causing the growth and by > how much. I wonder how much of this is from some of the fancier template > things we have (ex. the 600 template expansions from StyleBuilder) > > > On Fri, Mar 22, 2013 at 5:22 AM, Eric Seidel <[email protected]> wrote: >> >> It seems like it should be trivial to set up an EWS bot to track size >> changes. >> >> It would (sadly) need to clobber, as my understanding is that >> incremental builds are not deterministic in their sizes: >> https://code.google.com/p/chromium/issues/detail?id=110002 >> (our bug about this for Chromium Try servers). >> >> Thankfully the EWS is very well suited for this task. >> >> On Fri, Mar 22, 2013 at 1:29 AM, Benjamin Poulain <[email protected]> >> wrote: >> > On Fri, Mar 22, 2013 at 12:12 AM, Ryosuke Niwa <[email protected]> wrote: >> >> >> >> WebKit nightly build for r135421 dated November 21st, 2012 was 46.1MB. >> >> WebKit nightly build for r145786 dated March 13th, 2013 was 49.4MB. >> >> >> >> Our binary size increased by 7.2% in just 4 months. >> > >> > >> > I have been tracking this issue for a bit. I can send more detailed view >> > of >> > the growth if anyone is interested. >> > >> >> >> >> Is this a problem? I think it is. It means that we use more RAM when >> >> WebKit is loaded onto memory. It means that it takes longer to load >> >> WebKit >> >> into RAM. It means that auto-update, etc... various browsers that use >> >> WebKit >> >> needs to send more data over the network. 6MB costs you a ton if >> >> you're >> >> wiring over cellar network. >> > >> > >> > RAM space is not the only problem we have with big binaries. The bigger >> > our >> > code gets, the less efficiently we use the fast CPU caches and WebKit >> > gets >> > slower over time overall. >> > >> > On embedded, you typically have tiny caches and slower memory. This >> > leads to >> > a lot of memory pressure and we had to cut binary size sometimes to get >> > the >> > performance back. >> > >> >> What strategies can we use to address this problem? >> > >> > >> > I would like it if EWS could report growth and shrinkage somehow, and >> > have a >> > warning in case of abnormal growth. >> > >> > Benjamin >> > >> > _______________________________________________ >> > webkit-dev mailing list >> > [email protected] >> > https://lists.webkit.org/mailman/listinfo/webkit-dev >> > >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
