The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: bqt@update.uu.se (Johnny Billquist)
Subject: [TUHS] termcap vs terminfo
Date: Tue, 06 Jan 2015 18:33:44 +0100	[thread overview]
Message-ID: <54AC1C78.6090007@update.uu.se> (raw)
In-Reply-To: <CAEoi9W7Ke_AV8PjQ=i0kLK3PFUuXQBsFnR3a4A2hjqNTr88tJw@mail.gmail.com>

On 2015-01-06 17:56, Dan Cross wrote:
> On Tue, Jan 6, 2015 at 11:51 AM, Johnny Billquist <bqt at update.uu.se
> <mailto:bqt at update.uu.se>> wrote:
>
>     On 2015-01-06 17:32, Mary Ann Horton<mah at mhorton.net
>     <mailto:mah at mhorton.net>> wrote:
>
>         Even with TERMCAP in the environment, there's still that quadratic
>         algorithm every time vi starts up.
>
>
>     I must be stupid or something. What quadratic algorithm?
>     vi gets the "correct" terminal database entry directly from the
>     environment. Admittedly, getting any variable out of the environment
>     means a linear search of the environment, but that's about it.
>
>     What am I missing? And once you have that, any operation still means
>     either searching through the terminal definition for the right
>     function, which in itself is also linear, unless you hash that up in
>     your program. But I fail to see where the quadratic behavior comes in.
>
>
> I believe that Mary Ann is referring to repeatedly looking up
> (presumably different) elements in the entry.  Assuming that e.g. `vi`
> looks up O(n) elements, where $n$ is the number of elements, doing a
> linear scan for each, you'd end up with quadratic behavior.

Assuming that you'd look up all the elements of the termcap entry at 
startup, and did each one from scratch, yes.

> Hashing, or storing in some kind of balanced-tree like structure or
> something, would of course help but would also necessitate doing a copy
> and would entail some additional memory inefficiency.

Hashing would indeed cause some extra memory, but not necessarily any 
copying.
But that would beg the question, why is vi doing a repeated scan of the 
terminal entry at startup, if not to find all the capabilities and store 
this somewhere? And if doing a look for all of them, why not scan the 
string from start to finish and store the information as it is found? At 
which point we move from quadratic to linear time.

But now we're getting into the innards of vi, which I never looked at 
anyway, and I guess is less relevant in this thread anyway.

The short of it (from what I got out of it) is that the move from 
termcap to terminfo was mostly motivated by attribute name changing away 
from fixed 2 character names.

A secondary motivation would be performance, but I don't really buy that 
one. Since we only moved to terminfo on systems with plenty of memory, 
performance of termcap could easily be on par anyway.

Thanks for the insights.

	Johnny




  reply	other threads:[~2015-01-06 17:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.143.1420561935.3354.tuhs@minnie.tuhs.org>
2015-01-06 16:51 ` Johnny Billquist
2015-01-06 16:56   ` Dan Cross
2015-01-06 17:33     ` Johnny Billquist [this message]
2015-01-06 17:53       ` Dan Cross
     [not found] <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
2015-01-10 22:15 ` [TUHS] Termcap " David Barto
2015-01-10 22:43   ` Lyndon Nerenberg
2015-01-10 22:51     ` Lyndon Nerenberg
2015-01-10 23:02     ` Christian Neukirchen
2015-01-10 23:04       ` Lyndon Nerenberg
2015-01-11 16:48         ` Christian Neukirchen
2015-01-11  2:06     ` Dave Horsfall
2015-01-11  9:16       ` Diomidis Spinellis
2015-01-12 15:36       ` Clem Cole
2015-01-06 21:32 [TUHS] termcap " Mary Ann Horton
  -- strict thread matches above, loose matches on Subject: below --
2015-01-01 17:04 [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed) Warner Losh
2015-01-02 19:13 ` Erik E. Fair
2015-01-05  7:06   ` Peter Jeremy
2015-01-06  0:40     ` John Cowan
2015-01-06 12:22       ` arnold
2015-01-06 16:02         ` [TUHS] termcap vs terminfo Mary Ann Horton
2015-01-06 17:12           ` arnold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54AC1C78.6090007@update.uu.se \
    --to=bqt@update.uu.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).