core language sizes (Re: Another nil/false proposal)

[nop@...]

On Thu, 17 Jan 2002, Roberto Ierusalimschy wrote:

> On Thu, 17 Jan 2002 nop@nop.com wrote:
> 
> > For starters, there's size.
> >

> > nop@slothrop:~/python1.5-1.5.2.orig$ size python ~/lua/bin/lua
> >    text    data     bss     dec     hex filename
> >  315675   34448    7680  357803   575ab python
> >  102175    2716      32  104923   199db /home/nop/lua/bin/lua
> >
> 
> That was python 1.5. With python 2.2, on my machine (Solaris), I have:
> 
> text    data    bss     dec     hex     filename
> 577232  236608  12464   826304  c9bc0   /local/bin/python
> 83732   25135   884     109751  1acb7   ./lua

Yeah, on my Debian/SPARC box:

nop@slothrop:~$ uname -a
Linux slothrop 2.4.10 #1 Tue Oct 2 15:18:15 EDT 2001 sparc64 unknown
nop@slothrop:~/Python-2.2$ size python-O*
 615747  106328   11856  733931   b32eb python-O2
 721503  106328   11856  839687   cd007 python-O3

I picked Python 1.5 because that was the last big version before the
growth began.  (See also the Tcl 7.x to 8.x transition.)

That's a rather large amount of writable data in your Python 2.2.  The
data segment size is bad in that

  a) Systems without virtual memory have to allocate and copy all of
it on program startup.

  b) Systems with virtual memory will treat it as copy-on-write, some
of them charging the application for swap use due to potential future
dirtying of those pages.

  c) Even with copy-on-write, writing a single byte to a page will
force allocation of that page; unless the data is layed out carefully,
interspersing writable data with stuff that isn't written to will
allocate many more pages than is necessary.

  d) Some systems produce more efficient code for references to
non-data segment items.

This isn't to say that initialized data itself is bad; it should be
more efficient than manually malloc()ing an area and copying
initialized data to it.

On workstations these issues aren't important, but on smaller devices
they can really add up.  There are heap vs data vs text tradeoffs as
well; Lua 4.1 adds pushconst which helps a little with that.

Or maybe I'm just abnormally concerned with these issues for their own
sake.  Who knows.

Just for laughs, I spent a little time running around const'ing stuff
like doc strings and method defs in Python 2.2.  I cut the data size
of a minimal python executable from 105k to 55k without trying too
hard.  The 50k moved to the text segment, sure, but there was a slight
decrease in text size due to increased addressing efficiency---if I'm
remembering this right.

While we're at it:

   text    data     bss     dec     hex filename
 431687   26592    2464  460743   707c7 tcl8.2.3/unix/tclsh
 753594    9500    2344  765438   badfe perl-5.7.2/microperl
 595223    3168   56680  655071   9fedf ruby-1.6.5/miniruby

You obviously get a lot more external interface in some of these than
Lua, but these are the cores.

I suppose I should do some heap usage surveys too.

Jay