Re: [webkit-dev] Ever increasing binary size
On Mon, Apr 1, 2013 at 7:33 AM, Timothy Hatcher timo...@apple.com wrote: On Mar 22, 2013, at 3:12 AM, Ryosuke Niwa rn...@webkit.org 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. Keep in mind that the Safari's Web Inspector is in the nightly. Also all of the frameworks and their resources are in the nightly twice (for 10.7 and 10.8). Safari's Web Inspector framework is around 2.5 MB (uncompressed) in r135421 and 4.2 MB in r145786. A 68% increase (that I will investigate further). Most of that size comes from image resources that can't be compressed further by the disk image. They are also duplicated for each OS, but the disk image compression should cancel that out. Also the WebKit Web Inspector is in the nightly. It is 5.1 MB (uncompressed) in r135421 and 6.3 MB in r145786. A 24% increase. Again, mostly images. That's an interesting point. It would indeed be more interesting to track the in-memory size of binaries than the file size. I think the first course of action we can take is to start tracking the binary size so that we may detect huge spikes. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ever increasing binary size
On Mar 22, 2013, at 3:12 AM, Ryosuke Niwa rn...@webkit.org 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. Keep in mind that the Safari's Web Inspector is in the nightly. Also all of the frameworks and their resources are in the nightly twice (for 10.7 and 10.8). Safari's Web Inspector framework is around 2.5 MB (uncompressed) in r135421 and 4.2 MB in r145786. A 68% increase (that I will investigate further). Most of that size comes from image resources that can't be compressed further by the disk image. They are also duplicated for each OS, but the disk image compression should cancel that out. Also the WebKit Web Inspector is in the nightly. It is 5.1 MB (uncompressed) in r135421 and 6.3 MB in r145786. A 24% increase. Again, mostly images. So I don't think the majority of the download size increase correlates to in-memory size of the binaries. (See the link Eric sent later for that.) — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Ever increasing binary size
Hi, 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. 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. What strategies can we use to address this problem? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ever increasing binary size
On Fri, Mar 22, 2013 at 12:12 AM, Ryosuke Niwa rn...@webkit.org 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. Correction: r146449 dated March 21st, 2013. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ever increasing binary size
On Fri, Mar 22, 2013 at 12:12 AM, Ryosuke Niwa rn...@webkit.org 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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ever increasing binary size
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 benja...@webkit.org wrote: On Fri, Mar 22, 2013 at 12:12 AM, Ryosuke Niwa rn...@webkit.org 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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ever increasing binary size
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 e...@webkit.org 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 benja...@webkit.org wrote: On Fri, Mar 22, 2013 at 12:12 AM, Ryosuke Niwa rn...@webkit.org 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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ever increasing binary size
Perhaps useful to you: http://neugierig.org/software/chromium/bloat/ On Fri, Mar 22, 2013 at 12:06 PM, Elliott Sprehn espr...@chromium.org 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 e...@webkit.org 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 benja...@webkit.org wrote: On Fri, Mar 22, 2013 at 12:12 AM, Ryosuke Niwa rn...@webkit.org 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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
