Re: zsh 3.0 still intolerably slow on NeXTStep 3.2

[Geoff Wing <mason@primenet.com.au>]

Bart Schaefer replied to Timothy J. Luoma:
:} The drawing of the prompt (right and left) is still terribly slow,  
:} and if I go into a long command (ie a find command) and type, I can  
:} see the cursor jump to the beginning of the line and then back  
:} again.
:There are only two new hunks of refresh() in zle_refresh.c that I can see
:making any difference here.  First:
:    for (;;) {
:+	if (*nl && nl[1] == ol[1])	/* skip only if second chars match */
:	/* skip past all matching characters */
:	    for (; *nl && (*nl == *ol); nl++, ol++, ccs++) ;
:This seems to assume that when ol="ab..." and nl="ac..." that it's faster
:to go ahead and insert the string "ac" rather than move one character to
:the right and then insert "c".  This is not necessarily an optimization
:if the cursor is already positioned at or to the right of the "a" position,
:is it, Geoff?  Especially if "move to column x" is implemented as "move to
:column 0 and then move right x columns" by the terminal?

This reply is probably more technical than necessary for zsh-users but..
At a glance, it's only not an optimization once in a line.  It could probably
be improved if a check on  vcs - ccs  is made here.  (I'll think about it a
bit instead of sending in a rush patch (and Zoltan will be away for the next
week anyway).

:Tim, try deleting that line from refresh() and see what happens.
:
:Second:
:+		    /* if we've pushed off the right, truncate oldline */
:+			for (j = ccs - i, p1 = ol; *p1 && j + char_ins < winw;
:+			     p1++, j++);
:+			if (j + char_ins == winw)
:+			    *p1 = '\0';
:+			p1 = ol;
:Am I confused, or will this always cause the remainder of nl (anything off
:the right side of the current screen line?) to be reprinted (on the next
:cycle around the refresh() loop) followed by a clear-to-end-of-line, even
:if it hasn't changed?

ol should be an exact copy of what the rest of the current, single line is.
nl should be an exact copy of what it should be changed to.
The code listed above finds the end of ol if it is before the new last column,
otherwise where the new last column is represented in ol and puts a '\0' after.
A very simple example here would be:
Before this section of code, lines 633-65?. (0 is '\0' byte).
                                   *  (Asterisk is the last column)
                      matchingfoobar0 (ol)
                      we'rematchingf0 (nl)
                      matchingfoobar  (screen)
                      ^ cursor
After this section of code.
                           matchingf0 (ol) (0 put in ol by code listed above)
                           matchingf0 (nl)
                      we'rematchingf  (screen)
                           ^ cursor

And the next time around the refreshline() loop, all the matching characters
should be bypassed.

:I think its safe to delete that chunk as well, if deleting the first one
:doesn't make any difference; but I can't guarantee it.

This bit was a necessary change, not an optimization.  If, after you have
inserted characters off the right of the screen, you then do more deletes than
previous inserts, the characters don't come back.  You should only get spaces
at the end of the line and ol needs to represent this.
-- 
Geoff Wing [mason@primenet.com.au]   PrimeNet - Internet Consultancy
  Web: http://www.primenet.com.au/   Facsimile: +61-3-9819 3788