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: <400@nikhefh.UUCP>
Date: Mon, 26-Oct-87 08:36:57 EST
Article-I.D.: nikhefh.400
Posted: Mon Oct 26 08:36:57 1987
Date-Received: Wed, 28-Oct-87 02:27:37 EST
References: <8710242127.AA01675@ucbvax.Berkeley.EDU>
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 51

In article <8710242127.AA01675@ucbvax.Berkeley.EDU>, K538915@CZHRZU1A.BITNET writes:
> Jos Vermaseren T68@nikhefh.uucp writes
> >....................................... 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!....................................................
> **** mild flame follows ****
> **** flame off ****
A good editor can obviously read either mode. The argument was that
if you put the file sequentially in a buffer you can read much faster
then when you chop it up first into lines which is what some other
editors do. I haven't looked how tempus does it exactly as I didn't
feel like disassembling it.
> 
> >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.
> Which naturally depends on how many tabs are in the file.........
>   I don't think this is so serious. Anyway the obvious way
> to fix this is, to have the screen driver of Tempus  expand the tabs
> (something I will suggest to CCD in the letter I'm writing to them this
> weekend), not as Jos seems to suggest (I hope he didn't really mean that)
> expand them while reading the file.
> 
Of course that is the only way. Who in the world wants to expand the tabs
into blanks automatically. The problem with Tempus is that you have to do
that to get a proper screen representation. In this process you loose all
the speed you gained in faster reading. Some benchmark for really big files:
The file was 970K, which was a complete disassembly of the ROM's. The computer
a 2.5 Mbyte 260ST. The file had tabs and only a linefeed at the end of each
line ( this saves 60000 returns, one for each line )
:
Reading from hard disk:
Tempus 13sec, STedi 18 sec.
Then the tabs had to be expanded with tempus which took more than 5 minutes
(ever heard the word garbage collection). The problem with the linefeeds had
to be solved by having STedi write the file first with the returns.
The file written with the expanded tabs takes about 1.6 Mbytes. Reading such
a file takes more than 18 sec. My experience is that most editors make a
mess of tabs.

Anyway this is all beside the point, this point being that reading speeds are more or
less between 50K and 100K /sec from hard disk if the author has been working
hard on speed. The differences lie in the exact configuration of the memory
internally.

For the next battle: How about timing the searching algorithms.
Keep tuned in......

Jos Vermaseren
T68@nikhefh.hep.nl or T68@nikhefh.uucp