unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: geza.herman@gmail.com
Cc: 62352@debbugs.gnu.org, gregory@heytings.org
Subject: bug#62352: Very slow scroll-down-line with a lot of text properties
Date: Sun, 26 Mar 2023 07:55:08 +0300	[thread overview]
Message-ID: <834jq8az83.fsf@gnu.org> (raw)
In-Reply-To: <aafc974d-56d1-4dce-7586-c1ad64aceb1b@gmail.com> (message from Herman, Géza on Sat, 25 Mar 2023 22:39:34 +0100)

> Date: Sat, 25 Mar 2023 22:39:34 +0100
> Cc: gregory@heytings.org, 62352@debbugs.gnu.org
> From: Herman, Géza <geza.herman@gmail.com>
> 
> >> I'm not necessarily suggesting a cache. Maybe it's better to actually
> >> always manage additional data structures. So, if a text property is
> >> added, it's not just set for the specific character area, but it will
> >> also modify search structures right away. So additional data structures
> >> were always in sync. Sure, it has some overhead. But if emacs does a lot
> >> of linear searches (and having a look at these functions, I see a lot of
> >> linear searches), this overhead will be quickly mitigated by the much
> >> faster searches. For example, if emacs had a list which only contained
> >> text segments with the composition property, the current 500-char area
> >> search will be much faster.
> > Emacs already handles text properties using an efficient data
> > structure, see intervals.c.  Feel free to suggest improvements to the
> > algorithms we use there.
> The problem is not there. The problem is that find_composition is only 
> interested in the composition property, yet it scans all the properties 
> linearly.

It doesn't scan linearly.  It calls next-single-property-change, which
traverses the interval tree we use for storing text properties.
Please take a look at the implementation of
next-single-property-change in textprop.c.

> And it scans it for 500 characters. This file has a lot of 
> properties, this means a lot of unnecessary and duplicated work (because 
> it does this for each character displayed, or something like this). If 
> the composition property had its own list, then this problem wouldn't exist.

If the composition property had its own data structure, Emacs would
need to search them both when it looks for a change in _any_ property
(something that happens quite a lot in other places), and handle
various combinations of hits in both data structures.  That'd be a
significant complication for a small gain.





  reply	other threads:[~2023-03-26  4:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 20:01 bug#62352: Very slow scroll-down-line with a lot of text properties Herman, Geza
2023-03-21 20:26 ` Eli Zaretskii
2023-03-21 20:39   ` Herman, Géza
2023-03-21 21:58   ` Gregory Heytings
2023-03-25 11:58     ` Eli Zaretskii
2023-03-25 12:33       ` Herman, Géza
2023-03-25 12:42         ` Eli Zaretskii
2023-03-25 13:41           ` Herman, Géza
2023-03-25 14:02             ` Eli Zaretskii
2023-03-25 15:24               ` Herman, Géza
2023-03-25 16:20                 ` Eli Zaretskii
2023-03-25 17:38                   ` Herman, Géza
2023-03-25 17:49                     ` Eli Zaretskii
2023-03-25 21:39                       ` Herman, Géza
2023-03-26  4:55                         ` Eli Zaretskii [this message]
2023-03-26  7:14                           ` Herman, Géza

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=834jq8az83.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=62352@debbugs.gnu.org \
    --cc=geza.herman@gmail.com \
    --cc=gregory@heytings.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).