Re: Long lines and bidi

[Eli Zaretskii]

> Date: Mon, 11 Feb 2013 11:54:57 +0400
> From: Dmitry Antipov <address@hidden>
> CC: Eli Zaretskii <address@hidden>, Paul Eggert <address@hidden>
> 
> On 02/11/2013 09:43 AM, Dmitry Antipov wrote:
> 
> > Yet another interesting profile (generated by scroll-both micro-benchmark 
> > with
> > r111730) is shown below.
> >
> > Input is 4K lines, each line is ~27K bytes, Imla'ei (modern Arabic) script. 
> > IIUC
> > this R2L text with long lines should push bidi really hard, but ... bidi 
> > core
> > routines (by itself) are almost irrelevant in the profile:
> >
> >      39.96%        emacs  emacs                          [.] scan_buffer
> >      28.72%        emacs  emacs                          [.] 
> > buf_charpos_to_bytepos
> >      21.82%        emacs  emacs                          [.] 
> > buf_bytepos_to_charpos
> >       0.59%        emacs  emacs                          [.] 
> > re_match_2_internal
> 
> ... and with Paul's mem(r)chr patch it is:
> 
>      43.38%        emacs  emacs                          [.] 
> buf_charpos_to_bytepos
>      28.42%        emacs  emacs                          [.] 
> buf_bytepos_to_charpos
>      13.10%        emacs  libc-2.16.so                   [.] memrchr
>       0.85%        emacs  emacs                          [.] 
> re_match_2_internal

Without absolute times, it's hard to judge the improvement.

> So I should vote YES. This is simple optimization which really makes sense,
> and I suspect that the "less usual" input is, the more sense it has.

I'm not opposed to using memchr where possible.  I'm just saying that
we should NOT regard this as any kind of solution for the long-lines
problem with the current display engine.  To fix that problem, we need
to speed up redisplay by one or two orders of magnitude (it currently
takes several hundreds of milliseconds to several seconds; it should
take a few milliseconds, 10 msec max).  That is a far cry from 25%
improvement we will get with memchr.