Switching to ncurses

Jakub Jelinek jakub at redhat.com
Fri Dec 1 09:45:18 UTC 2006


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 (at least in FC6 ncurses; I know
many libraries are much bigger, but bash and similar programs are
really performance critical, slowing down all configure scripts, libtool
etc. by say 50% is not acceptable I guess) is .data.rel.ro:

  [15] .ctors            PROGBITS        000000346904e088 04e088 000010 00  WA  0   0  8
  [16] .dtors            PROGBITS        000000346904e098 04e098 000010 00  WA  0   0  8
  [17] .jcr              PROGBITS        000000346904e0a8 04e0a8 000008 00  WA  0   0  8
  [18] .data.rel.ro      PROGBITS        000000346904e0c0 04e0c0 00c4e8 00  WA  0   0 32
  [19] .dynamic          DYNAMIC         000000346905a5a8 05a5a8 0001a0 10  WA  3   0  8
  [20] .got              PROGBITS        000000346905a748 05a748 0001f0 08  WA  0   0  8
  [21] .got.plt          PROGBITS        000000346905a938 05a938 000940 08  WA  0   0  8
  [22] .data             PROGBITS        000000346905b280 05b280 000b40 00  WA  0   0 32
  [23] .bss              NOBITS          000000346905bdc0 05bdc0 000e08 00  WA  0   0 32

There is a bunch of quite big objects:

   121: 0000003469050fc0  7960 OBJECT  GLOBAL DEFAULT   18 _nc_cap_hash_table
   129: 0000003468e244b0    18 FUNC    GLOBAL DEFAULT   10 bkgd
   176: 000000346904e0e0   360 OBJECT  GLOBAL DEFAULT   18 boolcodes
   189: 0000003468e2aa50    18 FUNC    GLOBAL DEFAULT   10 scrollok
   196: 0000003468e24490    18 FUNC    GLOBAL DEFAULT   10 bkgdset
   244: 0000003468e21c50    18 FUNC    GLOBAL DEFAULT   10 clearok
   249: 0000003469058160  3320 OBJECT  GLOBAL DEFAULT   18 strnames
   261: 0000003469057d60   360 OBJECT  GLOBAL DEFAULT   18 boolfnames
   262: 000000346904e260   320 OBJECT  GLOBAL DEFAULT   18 numcodes
   294: 0000003469057220  2480 OBJECT  GLOBAL DEFAULT   18 _nc_key_names
   311: 000000346904f0a0  7960 OBJECT  GLOBAL DEFAULT   18 _nc_info_hash_table
   341: 0000003469052ee0  1080 OBJECT  GLOBAL DEFAULT   18 _nc_capalias_table
   344: 0000003468e243a0    18 FUNC    GLOBAL DEFAULT   10 echochar
   345: 0000003469058020   320 OBJECT  GLOBAL DEFAULT   18 numfnames
   378: 0000003468e24370    18 FUNC    GLOBAL DEFAULT   10 addch
   403: 0000003469058e60  3320 OBJECT  GLOBAL DEFAULT   18 strfnames
   422: 0000003469057be0   360 OBJECT  GLOBAL DEFAULT   18 boolnames
   440: 0000003468e25af0    18 FUNC    GLOBAL DEFAULT   10 leaveok
   467: 0000003468e23f50    18 FUNC    GLOBAL DEFAULT   10 insch
   488: 000000346904e3a0  3320 OBJECT  GLOBAL DEFAULT   18 strcodes
   515: 0000003468e3ad40    18 FUNC    GLOBAL DEFAULT   10 notimeout
   525: 0000003469057ee0   320 OBJECT  GLOBAL DEFAULT   18 numnames
   547: 0000003469053320   168 OBJECT  GLOBAL DEFAULT   18 _nc_infoalias_table
   551: 0000003468e2d5b0    18 FUNC    GLOBAL DEFAULT   10 syncok

and 3850 relative relocations.

Several of these are used only by code which parses the terminfo sources,
does that really have to be in a library that is used by all programs?
Is there anything but tic (or a couple of other ncurses utilities)
which parses the terminfo sources?

I think if it makes sense to remove termcap and replace it only with ncurses
(I'm not convinced), then the first step needs to be change ncurses so that
it is not a kitchen sink library.

	Jakub




More information about the fedora-devel-list mailing list