bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers

[Eli Zaretskii]

> Date: Mon, 20 Jun 2016 11:41:17 +1200
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: 23801@debbugs.gnu.org
> 
> > Can you reproduce the problem using 'ls'?
> 
> No, the majority of commands do respond quickly.
> 
> I suspect you'll need to do something which repaints the entire 
> terminal.

I don't understand what that means.  The output from "ls" repaints the
entire terminal as well, as it produces 1500 lines, much more than is
shown in the window.

Perhaps you mean cursor motion commands, i.e. escape sequences that
move the cursor up and down the screen, not just down?  But if that is
the reason, I'd expect to see its signs in the profile, which was not
the case, I think.  If you load term.el (not the .elc file!), and then
run your experiments under the profiler (profiler-start), what does
profiler-report produce?

> Both previous examples are drawing a background colour (before 
> eventually
> drawing some text over the top, which happens quickly). Perhaps there 
> are
> a ton of escape sequences being processed for the colours?

Probably, but I don't see how bidirectional display could slow down
this processing, because AFAIU these escape sequences are converted to
faces that are put on the displayed text, something that doesn't
involve the bidirectional reordering for display at all.

> I guess it simply depends on exactly what each application is
> doing. GNU Midnight Commander is a file manager. I think "mc"
> followed by "exit" should be a pretty easy/safe test for you to try?

My problem is precisely that I cannot figure out what could the
application be doing that would be so profoundly affected by
bidirectional display.

Does making the screen buffer (term-buffer-maximum-size) smaller help
in any way?