Switching to ncurses

[Bernardo Innocenti]

Miroslav Lichvar wrote:

>> 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.
> 
> $ ps -o rss,comm
>   RSS COMMAND
>  1428 bash_termcap
>  1480 bash_curses
> 
> Not sure it proves anything.

We see almost exactly the +50KB size difference reported
by "size".

The fact that bash also carries an additional 1400KB of bloat
does not make the ncurses problem more appealing : - )


> Note that termcap has everything in one big file. A simple program
> doing just tgetent() and tgetstr() is significantly faster with
> ncurses.

I too dislike big binary files, but I would at least hope it's being
loaded with mmap() and/or has at least an index to seek to the correct
terminal as an O(1) operation.


> $ time ( a=0;while [ $a -lt 1000 ]; do a=$[$a + 1] && ./testtermcap <
> /dev/null &> /dev/null; done )
> 
> real	0m2.078s
> user	0m1.137s
> sys	0m0.936s
> 
> $ time ( a=0;while [ $a -lt 1000 ]; do a=$[$a + 1] && ./testncurses <
> /dev/null &> /dev/null; done )
> 
> real	0m1.464s
> user	0m0.496s
> sys	0m0.962s

Hmmm!  So termcap also has algoritmic disadvantages that outweight
its smaller size relative to ncurses.

This makes me prefer ncurses over termcap, but fixing its abnormal
data+bss size is still very desiderable.

-- 
   // Bernardo Innocenti - Develer S.r.l., R&D dept.
 \X/  http://www.develer.com/