Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!mcvax!unido!sbsvax!greim From: greim@sbsvax.UUCP (Michael Greim) Newsgroups: comp.unix.wizards Subject: Re: terminfo Summary: Yes, you can speed up termcap Keywords: terminfo, curses Message-ID: <626@sbsvax.UUCP> Date: 15 Sep 88 11:22:42 GMT References: <508@altos86.UUCP> <10544@ulysses.homer.nj.att.com> <1389@zen.co.uk> <1486@ficc.uu.net> Organization: Universitaet des Saarlandes, Saarbruecken, West Germany Lines: 77 In article <1486@ficc.uu.net>, peter@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@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