Switching to ncurses

[Jakub Jelinek]

On Fri, Dec 01, 2006 at 11:00:54AM +0100, Arjan van de Ven wrote:
> On Fri, 2006-12-01 at 04:45 -0500, Jakub Jelinek wrote:
> > On Fri, Dec 01, 2006 at 10:13:55AM +0100, Bernardo Innocenti wrote:
> > > Are we still planning to completely replace termcap with
> > > ncurses in Fedora?
> > > 
> > > While I welcome reducing the number of dupe packages, I'm
> > > worried by the impact of this change on the size and
> > > performance of many core programs.
> > > 
> > > libncurses is much bigger than libtermcap, and also has
> > > oddly large .bss and .data sections:
> > > 
> > > bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2
> > >   text    data     bss     dec     hex filename
> > > 319006   56608    3592  379206   5c946 /lib64/libncurses.so.5
> > >  10483     788     112   11383    2c77 /lib64/libtermcap.so.2
> > > 
> > > this is going to impact very negatively on the RSS of several
> > > critical programs such as bash and python.
> > 
> > The really big writable section
> 
> how much of that would be missing const ?

The 2 biggest objects (8KB each) are const, pregenerated array
of:
const struct name_table_entry * const _nc_{info,cap}_hash_table[] =
{
        0,
        0,
        0,
        0,
        0,
        0,
        _nc_info_table + 465,
        0,
        0,
        0,
        0,
        0,
        _nc_info_table + 261,
...
};

I think the easiest would be just nuke the terminfo source
parsing routines from libncurses*.so, _nc_read_entry_source nor
_nc_parse_entry aren't even prototyped in any installed ncurses
headers.  It can be IMHO moved to libtic.a which will be linked
into ncurses utilities that need it.

If that is not possible, there are other options, e.g. switching
to a more compact and relocation friendly representation.
In those 2 big (sparse) tables all entries are either
0 or _nc_{info,cap}_table + small const offset >= 0 < 512.
Representing it as array of short int where -1 would mean
the current 0 and 0 .. 511 would mean _nc_info_table + that_value
would be trivial, save 2x6KB of memory and save hundreds of relocations.
Guess other large .data.rel.ro objects could be treated similarly,
again with a < 10 line change in code using the tables and some changes
in the generator.

	Jakub