DLLOYD@TUCC.BITNET (10/19/87)
Can anyone comment on the reason for the appalling slow text read and write times of the various editors on the ST. I find 1st word and wordwriter to be almost useless because of this and even the simple text editor STEDT (public domain) takes more time to load up a Fortran source file than my compilier takes to compile it! In order to get even simple features like word delete, fast jumps around the body of a large text file, etc. I prefer the public domain program STWRITER. It doesn't make much use of GEM (no windows) and does not have a "what you see is what you get" format, but it is reasonably fast. There is also a public domain program called CONVERT that will convert (what else?) STWRITER files into a form suitable for importing into Publishing Partner. Then if you've got the time... L. R. Fortney, Physics Dept, Duke Univ. DLLOYD@TUCC
t68@nikhefh.UUCP (Jos Vermaseren) (10/20/87)
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
K538915@CZHRZU1A.BITNET (10/25/87)
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 **** It just happens to be, that while the CP/M, MS-DOS and GEMDOS family of operating systems do not enforce any particular end-of-line marker, it IS convention to use CR LF (carrige return linefeed). How many UN*X utilites break if you suddenly decide to use CR LF as eol instead of LF ? Or what if I decide to start using RS (record separator) as eol? You would correctly say, that's my problem. So if you want to use LF, do so, but don't complain if 90% of all programs break. **** flame off **** Anyway since the behaviour of Tempus in above case was without question a bug, it was fixed in version 1.10 (over three months ago!). >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......... Just a few times I mesured with Tempus: Read a 275kB file from a 5MB partition on a SH204: < 3 sec Write a 275kB file to a 5MB partition (80% full): ~9 sec Compress above file (=GNU-Emacs tabify)-> 7111 Tabs: < 2 sec Expand above file ('de-tabify'): ~20 sec Change all 7111 tabs to '+': < 5 sec The file was 275 kB of Pascal source with about 8000 lines. As you really only have to expand the file once (if you use tab in the editor spaces are inserted), 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. Simon Poole Bitnet: K538915@CZHRZU1A UUCP: ...mcvax!cernvax!forty2!poole PS: due to a major slipup in our computing center (=CZHRZU1A), all mail sent to me before last Friday has got lost (> 60 messages GRRRRRRRRRRRRR!).
t68@nikhefh.UUCP (Jos Vermaseren) (10/26/87)
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