bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Speed up redrawing in the common case for UTF-8


From: Tim Waugh
Subject: Speed up redrawing in the common case for UTF-8
Date: Fri, 28 Nov 2003 13:45:43 +0000
User-agent: Mutt/1.4.1i

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DSHELL -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib 
-D_FILE_OFFSET_BITS=64 -O2 -g -pipe -march=i386 -mcpu=i686
uname output: Linux gene.surrey.redhat.com 2.4.22-1.2115.nptl #1 Wed Oct 29 
15:42:51 EST 2003 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu

Bash Version: 2.05b
Patch Level: 0
Release Status: release

Description:
        When typing a long command line into a bash prompt, with a
        UTF-8 locale, it takes a noticeable amount of time for each
        character to appear; the longer the line the more noticeable
        the delay.  When pasting a long command line in the effect can
        be seen very easily.

Repeat-By:
        Paste 2000 'x' characters into a bash command line buffer and
        watch each successive line take longer and longer.

Fix:
        The delay is caused by the find-first-different test in
        update_line in lib/readline/display.c.  For UTF-8 locales each
        multibyte character is first interpreted, and then compared
        with its counterpart in the new command line.  When the only
        difference is that some characters have been added to or
        removed from the end of the line this is all unnecessary.

        The solution below is based on the observation that both
        command lines, old and new, have an integral number of
        characters i.e. no partial multibyte characters.  So if one of
        the lines is the same as the other, up to its length, that
        length tells us the offsets we were originally trying to
        compute.

        For the less common case of editing the middle of the command
        line I think the extra memcmp time is probably lost in the
        noise of multibyte processing.

--- bash-2.05b/lib/readline/display.c.slow      2003-11-28 11:33:50.000000000 
+0000
+++ bash-2.05b/lib/readline/display.c   2003-11-28 12:12:37.000000000 +0000
@@ -1126,6 +1126,15 @@
 #if defined (HANDLE_MULTIBYTE)
   if (MB_CUR_MAX > 1 && rl_byte_oriented == 0)
     {
+      /* First try to see if one line is the same as the other except for
+       * some additional characters, to save calls to _rl_compare_chars etc. */
+      int maxsame = omax < nmax ? omax : nmax; /* both are non-negative */
+      if (!memcmp (old, new, maxsame))
+       {
+         ofd = old + maxsame;
+         nfd = new + maxsame;
+       }
+      else {
       memset (&ps_new, 0, sizeof(mbstate_t));
       memset (&ps_old, 0, sizeof(mbstate_t));
 
@@ -1139,6 +1148,7 @@
          ofd = old + old_offset;
          nfd = new + new_offset;
        }
+      }
     }
   else
 #endif




reply via email to

[Prev in Thread] Current Thread [Next in Thread]