[webkit-dev] Ever increasing binary size

[Eric Seidel]

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
>