GNU bug report logs - #72830
Big rectangular selections are slow

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: 72830 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> linkov.net>
Subject: bug#72830: Big rectangular selections are slow
Date: Tue, 27 Aug 2024 14:39:37 +0200

Selecting rectangles that stretch across many lines is very slow. Recipe:

  C-x b example RET
  C-u 60 x C-u 200000 M-x duplicate-dwim RET C-a
  C-x SPC
  M-> C-f C-f C-f C-f

Each keystroke at the end lags noticeably, to the point that this isn't practical.

Why this matters: rectangular selections are very useful for editing large amount of data in a homogeneous way, and such a file (12 MB) isn't huge.

Possible causes:

- Slow `region-beginning` and `region-end`.
  Fixed on master (3a8222e7).

- `select-active-regions` makes each selection change very expensive.
  Can be set to nil by the user, but I really suggest that we change the default to nil, at least for non-X11 since the default assumes old-school X11 PRIMARY selection which is alien on most other platforms.

- Slow `rectangle--highlight-for-redisplay`. This is the remaining cause.
Profiling shows that most of the time is spent in the function passed to `apply-on-rectangle`.
Here is an excerpt of that profile:

|        Weight         Self
|  31.93 Gc   57.4%   103.06 Mc   Fmove_to_column
|  31.52 Gc   56.7%   884.80 Mc     scan_for_column
|  14.45 Gc   26.0%    27.82 Mc       check_display_width
|  14.30 Gc   25.7%   648.23 Mc         get_char_property_and_overlay
|   9.79 Gc   17.6%     1.07 Gc           itree_iterator_next
|   2.00 Gc    3.6%    42.68 Mc           Fget_text_property
| 743.88 Mc    1.3%   154.63 Mc           itree_iterator_start
| 678.00 Mc    1.2%   183.02 Mc           lookup_char_property
|   7.28 Gc   13.0%   155.15 Mc       skip_invisible
|   4.22 Gc    7.6%   701.27 Mc       composition_compute_stop_pos
|   3.00 Gc    5.3%   153.86 Mc       window_loop
|   1.28 Gc    2.3%   216.97 Mc       find_newline
|   2.28 Gc    4.1%    80.59 Mc   Fmove_overlay
|   1.46 Gc    2.6%    40.18 Mc   lookup_char_property

This excludes GC costs (about 18 % I think), which in turn is dominated by scanning overlays.

It's a bit surprising (to me) how expensive move-to-column is. The text is all-ASCII without any complications (no long lines, properties, etc).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.