unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Phil Sainty <psainty@orcon.net.nz>
To: 23801@debbugs.gnu.org
Subject: bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers
Date: Tue, 21 Jun 2016 02:35:46 +1200	[thread overview]
Message-ID: <5767FF42.10208@orcon.net.nz> (raw)
In-Reply-To: <0b5cd701be526f2391bb8fe15bb120c7@mail.orcon.net.nz>

Progress...

I believe the terminal screen refreshes which exhibit the issue
are performed by inserting spaces (with a background colour).

It turns out that we can demonstrate this issue without any other
programs, simply by inserting spaces (or tabs).

Most critically, inserting non-whitespace characters does NOT
cause performance issues! (At least not the ones I've tried.)

(This presumably explains why midnight commander's initial draw
was so comparatively speedy, as it was drawing the final content
from the outset, rather than clearing the screen first and then
writing the content.)


Recipe:

emacs -Q (and maximise the terminal or GUI frame)
M-x term (and run a shell)
printf "%10000s" x

(to insert an 'x' preceded by 9,999 spaces.)

That's not as obvious without a background colour, but we can
provide that easily enough:

printf "\033[41m%10000s\033[47m" x

(Drawing in red, and reverting to a white background. Use 40m
in the final sequence if you need to revert to black instead.)


Bash supports numeric prefix arguments for repetition just like
Emacs, so you can also insert lots of spaces like so:

M-10000 SPC

You can insert 1,000 TABs with:
M-1000 C-v C-i


With this approach we are entering (but not yet submitting) a
command, and I further note that using C-u at this point to erase
our input is also really slow to complete -- but again, only when
it is whitespace being 'erased'.

e.g. M-10000 x C-u is perfectly speedy.






  reply	other threads:[~2016-06-20 14:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-19 10:04 bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers Phil Sainty
2016-06-19 16:26 ` Eli Zaretskii
2016-06-19 23:41   ` Phil Sainty
2016-06-20  0:00     ` Phil Sainty
2016-06-20 14:35       ` Phil Sainty [this message]
2016-06-20 15:05         ` Eli Zaretskii
2016-06-21 18:47         ` Eli Zaretskii
2016-06-22 13:13           ` Phil Sainty
2016-06-22 15:27             ` Eli Zaretskii
2016-06-26  0:35               ` Phil Sainty
2016-06-26 16:45                 ` Eli Zaretskii
2016-06-26 16:45                 ` Eli Zaretskii
2016-06-20 14:28     ` Eli Zaretskii
2016-06-20 15:07       ` Phil Sainty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5767FF42.10208@orcon.net.nz \
    --to=psainty@orcon.net.nz \
    --cc=23801@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).