unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: David Ponce via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 72689@debbugs.gnu.org
Subject: bug#72689: 31.0.50; Proposal to improve string-pixel-width
Date: Sun, 18 Aug 2024 08:05:04 +0200	[thread overview]
Message-ID: <d176d504-aa0b-4bac-b332-30f08173554b@orange.fr> (raw)
In-Reply-To: <86bk1q1m0l.fsf@gnu.org>

On 18/08/2024 6:40 AM, Eli Zaretskii wrote:
>> Date: Sun, 18 Aug 2024 00:03:22 +0200
>> From:  David Ponce via "Bug reports for GNU Emacs,
>>   the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> The function string-pixel-width is essential for calculating pixel
>> dimensions, especially for UI components. And in this context this
>> function can be called very often when the display is refreshed.
>>
>> I propose the attached patch to make string-pixel-width faster while
>> using less memory, as shown by the following results of a basic
>> benchmark run in emacs -Q to compare the current implementation and this
>> proposal:
>>
>> ;; Basic benchmark
>> (let* ((text1 (make-string 1000 ?x))
>>          (text2 (propertize text1 'line-prefix "XXXX ")))
>>     (list
>>      (string-pixel-width text1)
>>      (string-pixel-width text2)
>>      (progn (garbage-collect)
>>             (benchmark-run 10000 (string-pixel-width text1)))
>>      (progn (garbage-collect)
>>             (benchmark-run 10000 (string-pixel-width text2)))
>>      ;;(insert text "\n")
>>      ))
>>
>> ;; Result with current implementation (4 run):
>> (12000 12000 (1.854707611 17 0.120106147) (1.884129905 17 0.12258791599999996))
>>
>> (12000 12000 (1.846544798 17 0.12243524500000003) (1.8822177530000002 17 0.12349287399999997))
>>
>> (12000 12000 (1.851244125 17 0.12162041699999998) (1.860517709 17 0.12352999599999998))
>>
>> (12000 12000 (1.8542218929999998 17 0.12164553900000001) (1.856302462 17 0.122891689))
>>
>> ;; Result with proposed implementation (4 run):
>> (12000 12000 (1.698974522 0 0.0) (1.727446 2 0.014782505999999973))
>>
>> (12000 12000 (1.701800124 0 0.0) (1.728024111 2 0.014718454999999908))
>>
>> (12000 12000 (1.6850850800000001 0 0.0) (1.732370238 2 0.014801913000000111))
>>
>> (12000 12000 (1.7356390130000001 0 0.0) (1.7858915800000001 2 0.014816158000000135))
>>
>>   From my observations, the new implementation is around 8% faster, and
>> trigger less GC.  When there is no line-prefix property to
>> remove, the new implementation doesn't trigger any GC after 10000 runs.
>> Otherwise, only 2 GC are triggered instead of 17.
>>
>> Maybe this proposal might be of interest, or at least provide some ideas
>> for improvement.
> 
> Thanks.  The idea SGTM, but I think the implementation needs to cater
> for the case where more than one execution thread performs this job
> "in parallel" (however improbable this could sound), so we need to be
> able to detect when this buffer is "busy".  The simplest way is to use
> some boolean buffer-local variable, which will be set non-nil when the
> function starts using the buffer and reset to nil when the function is
> done with its job.

Thanks.  Your point about "parallelism" is quite relevant.  However
I'm not sure I understand your suggestion to introduce a buffer-local
boolean variable.  In particular, what to do when the buffer-local
flag is set when entering the function?  Wait until the flag is
reset?  Create another buffer?

Perhaps for parallelism, using temporary buffers might be a better
approach?  But I have no idea how much stress would be put on Emacs if
thousands of temporary buffers were created/freed during a session?

Could you elaborate further?






  reply	other threads:[~2024-08-18  6:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-17 22:03 bug#72689: 31.0.50; Proposal to improve string-pixel-width David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18  4:40 ` Eli Zaretskii
2024-08-18  6:05   ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-08-18  9:15     ` Eli Zaretskii
2024-08-19  8:49       ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-20 15:12       ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-21 13:17         ` Eli Zaretskii
2024-08-21 20:43           ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-22  3:43             ` Eli Zaretskii
2024-08-22  9:48               ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-22 10:59                 ` Eli Zaretskii
2024-08-22 14:56                   ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-23  6:20                     ` Juri Linkov
2024-08-23  6:49                       ` Eli Zaretskii
2024-08-23  7:23                         ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-31  8:26                     ` Eli Zaretskii
2024-08-31 10:51                       ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-31 12:00                         ` Eli Zaretskii
2024-08-18  6:12 ` Jim Porter
2024-08-18  7:36   ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 16:35     ` Jim Porter
2024-08-18  9:23   ` Eli Zaretskii

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=d176d504-aa0b-4bac-b332-30f08173554b@orange.fr \
    --to=bug-gnu-emacs@gnu.org \
    --cc=72689@debbugs.gnu.org \
    --cc=da_vid@orange.fr \
    --cc=eliz@gnu.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).