t19@nikhefh.hep.nl (Geert J v Oldenborgh) (07/25/89)
I just played around a bit with Folded.
Here are some benchmarks against the other folding editor on the ST,
STedi (version 2.0beta). They are not quite fair: STedi is a commercial
product whereas Folded was given away free, and apologizes for the lack of
attention paid to speed. Furthermore, the PC and UNOX versions of STedi are
still in the beta-test stage only.
Reading a 87.5K file from cache, including start-up time:
Folded: 14.78 s
STedi: 2.22 s
Searching for the string ZZZZ at the end of the file:
Folded: 5.6 s
STedi: 0.5 s
Scrolling through the entire 3582 line file, using J/shift arrow:
Folded: 76.4 s
STedi: 11.4 s
Substitute one char -> one char, 1536 times (m->M):
Folded: 6.0 s
STedi: 1.5 s
Substitute "delta" -> "lange string" (this forces the line to be moved), 512
times:
Folded: 8.3 s
STedi: 0.8 s
Furthermore, I have some questions:
- How does one go to a specific line and edit it (as in
"Error on line 737 of ffdxc0.f: Wrongly nested DO statements")
(STedi: <Command>[737 opens all folds to get to this line)
- Is there no 'find matching bracket' command?
- The incremental search is quite annoying on a slow line, or even the
ST screen, is there a way to turn it off?
- Screen updates are too frequent.
I still do not like its concept of folding-by-indentation or seperate file
too much. The info in the file does not look too bad. Here is a screendump
of STedi (on UNOX), to prove that fold info in the file can add to readability:
-------------------------------------------------------------------------------
*###[ ffdcs:
subroutine ffdcs(cs3,ipi12,cy,cz,cdyz,cd2yzz,cdyzzy,cpi,cpiDpj,
+ ii,ns,isoort,ier)
***##*comment:***********************************************************
* ## declarations:
* ## check input:
* #[ normal case:
if ( isoort(1) .ne. isoort(9) .or. isoort(1) .gt. -10 ) then
if ( lwrite ) print *,'ffdcs: normal case'
.
some Fortran statements
.
endif
* #] normal case:
* #[ rotated R's:
.
rest of program
-------------------------------------------------------------------------------
I hope this helps identifying areas in which Folded can be improved,
Geert Jan van Oldenborgh
t19@nikhefh.hep.nltrb@stag.UUCP ( Todd Burkey ) (07/26/89)
In article <223@nikhefh.hep.nl> t19@nikhefh.hep.nl (Geert J v Oldenborgh) writes: >I just played around a bit with Folded. >Here are some benchmarks against the other folding editor on the ST, >STedi (version 2.0beta). They are not quite fair: STedi is a commercial >product whereas Folded was given away free, and apologizes for the lack of >attention paid to speed. Furthermore, the PC and UNOX versions of STedi are >still in the beta-test stage only. Yes...the main reason actually is probably due to the fact that although I originally started FOLDED on the ST, I did most of the development and completion testing of the code on Unix systems. As a result, I dropped all the blitting code, use of alternate memory pages, direct memory writing of fonts, etc in the final released version. With Turbo ST and now quick-ST, the screen updating in FOLDED speeds up a great deal, with no extra effort required on my part :-). If I wanted to make FOLDED into an expensive product, I would probably add a Gem interface and do some heavy assembly programming for the screen and search routines (although I doubt I would try to get as fast as Tempus). >Furthermore, I have some questions: >- How does one go to a specific line and edit it (as in > "Error on line 737 of ffdxc0.f: Wrongly nested DO statements") > (STedi: <Command>[737 opens all folds to get to this line) ^fg737 would move you to it...although to do more than a simple line edit you couldn't use folded's temporary unfold command, but rather would have to unfold your way to the line. I am looking into adding a 'goto real line number' command for the 1.0 release that unfolds on the way, for the same reason (and because the relational capability in folded needs it...the RGE (relate goto error) command will automatically open the file in error and goto the line number if you are editing the error listing file.) >- Is there no 'find matching bracket' command? Nope...never needed it. Although I do have matching brace and comment block logic already in the code, so may add an external command for it sometime. >- The incremental search is quite annoying on a slow line, or even the > ST screen, is there a way to turn it off? There will be in 1.0...I added both styles of searching recently while testing the 'emacs-like' human interface mode in FOLDED. >- Screen updates are too frequent. Yep...got kind of irritating when I was test installing FOLDED the other day on an Ardent over a 2400 baud line...Knew the delays weren't due to a slow computer :-). The 0.9e version that I'll be sending out soon still has some optimization needed in it for partial screen update handling. I am also looking at adding some TASM routines to speed things up on the IBM PC side, since the other editors that use assembly code routines for scrolling blow FOLDED away on the IBM PC from a screen updating point of view. Also, I am back in the PC (386) world at my new job, so have a more pressing need to get that sped up :-). >I still do not like its concept of folding-by-indentation or seperate file >too much. The info in the file does not look too bad. Sorry, but we are really talking about two type of FOLDING...as I said in previous notes, I needed a more generic technique that didn't impact at all on the files I was editing. I easily do half of my folding on documentation and general information files that I have heavily related with my source code...to stick all the folding and relational information into the files would simply be too messy a problem later on (i.e. needing to filter the info out every time I printed the text files...or worse yet, forgetting to filter it out.) I may allow an option to include the fold/relation info in a file at the users' choice, but I doubt that would ever be an internal default in FOLDED. -Todd Burkey pwcs!stag!trb
kbad@atari.UUCP (Ken Badertscher) (07/27/89)
t19@nikhefh.hep.nl (Geert J v Oldenborgh) writes: | I just played around a bit with Folded. [ benchmarks deleted ] | I still do not like its concept of folding-by-indentation or seperate file | too much. The info in the file does not look too bad. I'm sorry, but that fold info looked pretty nasty to me. I really like the way Todd has implemented the folding, using separate files. I imagine this scheme must make the relational features of FOLDED easier to implement as well (and thus, easier for us to hack on! ;-). Your points about speed are right on, though - FOLDED could use quite a bit of optimizing. As you mentioned, though, Todd does explain in the documentation that it was brought up to be small and functional, and not necessarily a speed demon. One thing I really like is the way the screen redraws (from the line you're on outwards). But I too wish that it didn't redraw quite so much ;-). -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>
trb@stag.UUCP ( Todd Burkey ) (07/29/89)
In article <1627@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes: >One thing I really like is the way the screen redraws (from the line >you're on outwards). But I too wish that it didn't redraw quite so much ;-). I'll be optimizing the excess redraws out in 1.0...I don't notice it on Unix, since I usually have my terminal set at 19,200 or 38,400, but I recently started working for a company whose main development system is IBM PC based (286/386), so I've been optimizing some things out of sheer necessity :-). And yes, I'll still port things back to my ST's, even though I'm re-entering the world of Windows, Turbo C, Norton, and worms (segments) once again. BTW, Say hi to Sig from whats left of the ex-ETA gang here in the Cities... Most of the ex-ETA people I know have moved out-state, but some of us fools like hot summers and cold winters. -Todd Burkey pwcs!stag!trb