[webkit-dev] Ever increasing binary size

Eric Seidel eric at webkit.org
Fri Mar 22 12:36:27 PDT 2013


Perhaps useful to you:
http://neugierig.org/software/chromium/bloat/

On Fri, Mar 22, 2013 at 12:06 PM, Elliott Sprehn <esprehn at 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 <eric at 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 <benjamin at webkit.org>
>> wrote:
>> > On Fri, Mar 22, 2013 at 12:12 AM, Ryosuke Niwa <rniwa at 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 at lists.webkit.org
>> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>> >
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>


More information about the webkit-dev mailing list