On Jul 7, 2009, at 2:16 PM, T Ziomek wrote:
On Tue, Jul 07, 2009 at 02:34:32PM -0400, Mike Frysinger wrote:
On Tuesday 07 July 2009 12:30:18 Kumar Gala wrote:
Here are some size #'s
[galak@blarg u-boot-85xx]$ size u-boot text data bss dec hex filename 392040 50536 41957 484533 764b5 u-boot 397660 49500 42397 489557 77855 u-boot (new dlmalloc)
[galak@blarg u-boot-85xx]$ size common/dlmalloc.o text data bss dec hex filename 4768 1056 56 5880 16f8 common/dlmalloc.o 10390 16 492 10898 2a92 common/dlmalloc.o (new dlmalloc)
to say it has increased is an understatement. i cant imagine the upstream code increasing that much. perhaps we had trimmed/customized the implementation so as to shrink it ?
old dlmalloc: [galak@blarg u-boot-85xx]$ nm --size-sort common/dlmalloc.o
use the bloatcheck script to do a human readable compare between the two objects. you can find it in the linux kernel.
And/or, 'pahole' (Poke-a-hole) or some of the other "7 Dwarves" tools might help shed light on the differences.
LWN article http://lwn.net/Articles/335942/ (how I heard about them) GIT http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git OLS '07 paper http://oops.ghostprotocols.net:81/acme/7dwarves.pdf or http://ols.fedoraproject.org/OLS/Reprints-2007/melo-Reprint.pdf
Those would help if the data structs had gotten bigger. In this case the code itself is just larger.
- k