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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 72830 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#72830: Big rectangular selections are slow
Date: Tue, 27 Aug 2024 10:04:40 -0400

> Selecting rectangles that stretch across many lines is very slow.

Yup.

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

Seems unlikely.

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

Didn't think of that.  Do we re-set the PRIMARY every time the (active)
rectangular region is changed (i.e. after each key press)?  That would
make it non-scalable to large rectangular regions, indeed.

I thought the extraction of the region's content to put it into PRIMARY
and friends happened more lazily (e.g. when another application
requests the PRIMARY/CLIPBOARD, or when we deactivate the region).

> - Slow `rectangle--highlight-for-redisplay`.  This is the remaining cause.

This is the one I'm aware of.

> 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

I don't think we want to try and optimize the operations here because
that will only push the limit of what is "too large" a bit further.

More promising to me would be to try and skip any part of the buffer
that's not displayed.


        Stefan

Previous Next

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