unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Performance under bidi-paragraph-direction 'left-to-right vs bidi-display-reordering nil
@ 2019-11-24 10:41 Phil Sainty
  2019-11-24 16:00 ` Eli Zaretskii
  0 siblings, 1 reply; 3+ messages in thread
From: Phil Sainty @ 2019-11-24 10:41 UTC (permalink / raw)
  To: emacs-devel@gnu.org

As discussed in
https://lists.gnu.org/archive/html/emacs-devel/2019-07/msg00294.html
setting bidi-display-reordering nil isn't a supported/tested scenario,
and in so-long.el we changed that to set bidi-paragraph-direction to
'left-to-right instead.

I've just traced what seemed like a performance regression to this
change -- it's now apparent to me that there's a noticeable effect on
the redisplay performance having bidi-display-reordering enabled and
bidi-paragraph-direction set (at least under long-line situations)
which isn't experienced when bidi-display-reordering is disabled.

(Which doesn't seem entirely unexpected when stated like that.  I
think I'd simply been under a misapprehension that the change we'd
made would have more similar performance characteristics than is
actually the case.  I failed to notice anything at the time, because
I'd forgotten that I'd (setq-default bidi-display-reordering nil) in
my own config after bug 23801 -- believing back then that this was
a supported setting.)


As before, the JSON file from https://emacs.stackexchange.com/q/598
serves as an example:

wget
https://github.com/Wilfred/ReVo-utilities/blob/a4bdc40dd2656c496defc461fc19c403c8306d9f/revo-export/dictionary.json?raw=true
-O one_line.json

With global-so-long-mode enabled visiting one_line.json does not hang
Emacs; but for me there is a very noticeable 'lag' to interactive
movements around the early parts of that buffer which disappears
completely if I set bidi-display-reordering to nil.

I do imagine that the code already tries hard to be efficient, but if
there's any chance that with only bidi-paragraph-direction set we can
achieve performance nearer to that with bidi-display-reordering
disabled, that would seemingly be beneficial for files with extremely
long lines.

Failing that, it makes me wonder whether a nil bidi-display-reordering
should be under consideration as a supported state for end users, for
the performance benefits.


-Phil




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Performance under bidi-paragraph-direction 'left-to-right vs bidi-display-reordering nil
  2019-11-24 10:41 Performance under bidi-paragraph-direction 'left-to-right vs bidi-display-reordering nil Phil Sainty
@ 2019-11-24 16:00 ` Eli Zaretskii
  2019-11-30  8:42   ` Phil Sainty
  0 siblings, 1 reply; 3+ messages in thread
From: Eli Zaretskii @ 2019-11-24 16:00 UTC (permalink / raw)
  To: Phil Sainty; +Cc: emacs-devel

> From: Phil Sainty <psainty@orcon.net.nz>
> Date: Sun, 24 Nov 2019 23:41:56 +1300
> 
> As discussed in
> https://lists.gnu.org/archive/html/emacs-devel/2019-07/msg00294.html
> setting bidi-display-reordering nil isn't a supported/tested scenario,
> and in so-long.el we changed that to set bidi-paragraph-direction to
> 'left-to-right instead.
> 
> I've just traced what seemed like a performance regression to this
> change -- it's now apparent to me that there's a noticeable effect on
> the redisplay performance having bidi-display-reordering enabled and
> bidi-paragraph-direction set (at least under long-line situations)
> which isn't experienced when bidi-display-reordering is disabled.

I never said that setting bidi-paragraph-direction will provide the
same CPU savings as bidi-display-reordering.  If something I said
could have been interpreted that way, I apologize.  The latter
disables the bidi reordering engine; the former does not, it just
makes its job a little easier.

> I do imagine that the code already tries hard to be efficient, but if
> there's any chance that with only bidi-paragraph-direction set we can
> achieve performance nearer to that with bidi-display-reordering
> disabled, that would seemingly be beneficial for files with extremely
> long lines.

Maybe there's a chance, but I don't know how to optimize the code more
than it already is.  Ideas and patches are more than welcome in that
area.

> Failing that, it makes me wonder whether a nil bidi-display-reordering
> should be under consideration as a supported state for end users, for
> the performance benefits.

Sorry, no.  I will object to any core package setting
bidi-display-reordering to a nil value, as that causes the display
code to work in conditions it isn't supposed to, isn't being tested
in, and execute branches of code that aren't being actively developed.
Moreover, some parts of the display engine were written under the
basic assumption that this variable is never nil.  Setting that
variable to nil thus gives you an Emacs that cannot be trusted to
produce reliable results on display, so its only valid use is for
special tests and debugging.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Performance under bidi-paragraph-direction 'left-to-right vs bidi-display-reordering nil
  2019-11-24 16:00 ` Eli Zaretskii
@ 2019-11-30  8:42   ` Phil Sainty
  0 siblings, 0 replies; 3+ messages in thread
From: Phil Sainty @ 2019-11-30  8:42 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Just to follow this up, the new `bidi-inhibit-bpa' option added in
bug#38407 was also exactly what was needed to resolve the performance
issue I had alluded to here.


-Phil



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-11-30  8:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-24 10:41 Performance under bidi-paragraph-direction 'left-to-right vs bidi-display-reordering nil Phil Sainty
2019-11-24 16:00 ` Eli Zaretskii
2019-11-30  8:42   ` Phil Sainty

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).