terminfo

[Michael Greim]

In article <1486 at ficc.uu.net>, peter at ficc.uu.net (Peter da Silva) writes:
> 
> Nonesense. I wrote a termcap emulation for CP/M in 1981 that supported long
> names. I didn't actually time it, but since the code I wrote did a strcmp
> type search (abort as soon as a match fails) it might even be faster
> than a two-byte match (which is what you seem to be implying termcap does).
> 
> Also, there isn't much you can do to speed things up that will beat having
> a TERMCAP environment entry.
Yes, there is. I have defined some capabilities of my own, some with
string values of more than 100 characters (maps of linedrawing/semi-
graphic characters). The resulting termcap string got longer than
1024 bytes. I extended this to 2048. The initialization time of curses
went up to 1.78 seconds (processor time). This seemed a little bit long to me,
so I rewrote the lookup functions for termcap (tgetent). It does the following:
- the buffered string is more closely packed, i.e. leading tabs on lines
	are ommitted
- if we read the beginning of a string, and see that it is not the one
	we are looking for, we skip until beginnings of lines
- when we have the string we start sorting it into a list, using the
	slowest (but quickest to write) algorithm, i.e. shifting the rest
	of the list (but this is done with bcopy/memcpy)
- this is of course repeated until there are no more "tc=" entries, or
	we have a loop
Now, if we are looking for a capability, which is normally only done
once, we only have to emply binary search.
Normal lookup of capabilities consists of running along the whole
strings, stopping at ":" until we have found the capability or we are
at the end of the string. Assume the final termcap string is 1000 bytes
long, and you have to look up 100 entries (curses searches for more than
100). Then this will result in an average of 50 * 1000 character compares.
Wherease binary search in a list with 100 entries will result in, let's
say, less than 30 operations.
I found that this method reduced the startup time of curses from 1.78 seconds
to 0.74 seconds for the first entry in termcap. It also reduced startup
if the termcap string was taken from the environment variable TERMCAP,
but of course not by this magnitude. (see below)
The next step was to provide a program, which writes the resulting
list unto a file, and to modify the termcap lookup routine to first
look for this file. This is similar to the idea in terminfo to use
a compiled format. This reduced the startup time of curses to
0.48 seconds, if the files existed!

With some of the above mentioned modifications you can well make
the termcap routines faster.

Here the measurements again:

Initialization time of curry routine initscr in seconds processor time
on a SIEMENS PC-MX2, running SINIX v2.1

Standard termcap routines
	from file /etc/termcap       : 1.78
	from environment var TERMCAP : 1.64
new termcap routines
	from file /etc/termcap       : 0.74
	from environment var TERMCAP : 0.58
	from compiled file           : 0.48

These dates are to be taken with a grain of salt. The whole termcap entry
is in fact split into two files. Part one is in /etc/termcap, Part two
(extensions) are in /usr/lib/termlib/cy_*. This was done so that programs,
which rely on termcap entries not to be longer the 1024 characters, could
still work. If I put the termcap entry into the environment variable
then it would get only part one. But curses (CURRY) would still
read part two from file. (Yes, I know this is a glitch, but we wanted
to be able to use those old programs :-)

	-mg
-- 
email : greim at sbsvax.informatik.uni-saarland.dbp.de
  or  : ...!uunet!unido!sbsvax!greim
voice : +49 681 302 2434
snail : M. Greim, Universitaet des Saarlandes, FB 10 - Informatik,
        Bau 36, Im Stadtwald 15, D-6600 Saarbruecken 11, West Germany

# include <disclaimers/std.h>