zsh 3.0 still intolerably slow on NeXTStep 3.2

zsh 3.0 still intolerably slow on NeXTStep 3.2

[Timothy J. Luoma]

Well, I was hoping some miracle cure was going to come along and  
cure the slowness in zsh under NeXTStep 3.2.

It compiled fine, only complaining about a lack of 'makeinfo' when  
I did 'make install' and it claimed that there was nothing to be  
done for 'make all'

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.

Anyone have any clues what could be causing this?  I've tried to  
play with the BAUD settings, to no avail.

TjL

--------------------------------------------------------------------
Timothy J. Luoma <luomat@nerc.com>       http://www.nerc.com/~luomat
          My USENET feed is slow and not very reliable
NeXT info via email: send message with SUBJECT: send-ascii info
        NeXT Information:  http://www.nerc.com/~luomat/next

Re: zsh 3.0 still intolerably slow on NeXTStep 3.2

[Bart Schaefer]

On Aug 16,  2:44am, Timothy J. Luoma wrote:
} Subject: zsh 3.0 still intolerably slow on NeXTStep 3.2
}
} 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.
} 
} Anyone have any clues what could be causing this?

Does it make any difference whether your prompt is on the last line of
the terminal?

Does it make any difference if you `unset RPROMPT RPS1`?

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?

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?

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.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: zsh 3.0 still intolerably slow on NeXTStep 3.2

[Geoff Wing]

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

Re: zsh 3.0 still intolerably slow on NeXTStep 3.2

[Timothy J. Luoma]

I changed the 'refresh' line, but nothing changed.

The slowness is apparent when:
1) prompts are being drawn
2) when I use the up-arrow to go back through history commands... (and the down arrow as well)