Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!mcvax!nikhefh!t68
From: t68@nikhefh.UUCP (Jos Vermaseren)
Newsgroups: comp.sys.atari.st
Subject: Re: Text editors
Message-ID: <399@nikhefh.UUCP>
Date: Tue, 20-Oct-87 09:52:20 EDT
Article-I.D.: nikhefh.399
Posted: Tue Oct 20 09:52:20 1987
Date-Received: Wed, 21-Oct-87 06:55:09 EDT
References: <8710192031.AA18097@ucbvax.Berkeley.EDU>
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 44
Summary: Its laziness

In article <8710192031.AA18097@ucbvax.Berkeley.EDU>, DLLOYD@TUCC.BITNET writes:
> 
>   Can anyone comment on the reason for the appalling slow text
> read and write times of the various editors on the ST.

The reason lies in the use of getchar to read character by character
from the input. This can slow a program down to 1K per second like
1st word plus from a ramdisk on the mega ST. On the whole there are
two classes of editors: The ones that are written in C and use a standard
library and the ones that are ( usually ) written in assembler and do
all i/o from their own ( reasonably large ) buffers. These last ones can
reach speeds of 80K/second or more from ramdisk. The exact number depends
on how sophisticated the internal memory layout is. If this layout is
very simple reading speeds may be higher but this is paid back later
in terms of versatility or speed later. A good example of this is the
editor tempus which reads a little faster but assumes that each line ends
in <cr>+<lf>. A file with only <lf> gets still read, but each line misses
its last character! Also it cannot deal with tabs while reading. The tabs
have to be expanded afterwards resulting in a time which is much longer than
the 80K per second when all is considered. The fastest reading I have heard of
is with the editor of the Omikron basic package which reaches much more than
100K per second according to the authors. The STedi editor gets 80K per second.
Of the editors that are written in C I once used a microEmacs that was posted
more than a year ago. It could read about 8K per second from ramdisk, which was
considerably more than many other editors. Probably there are faster ones by
now ( we all know that Moshe Braner likes speed ).

The internal functions suffer all from the same problem: All editors that were
written with only portability in mind are usually rather slow as they use
slow library functions, do calls to functions to functions to functions etc
just to get one little thing done........

It is rather unreasonable to expect a really good editor for free as writing
such an editor is more than a manyear of work. Also a good editor is a non-
trivial piece of software that needs an extensive manual ( again a few months
work ). The Atari software market is actually not very large and rather
risky, so there are very few really good editors. Only people who don't
have to program for a living can be so economically inefficient as to write
one and they have a job during the day (usually).

I hope this helps.

Jos Vermaseren
T68@nikhefh.uucp