GNU bug report logs - #75342
[PATCH] Speed up asynchronous man page fontifying

Previous Next

To reply to this bug, email your comments to 75342 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Speed up asynchronous man page fontifying
Date: Sat, 4 Jan 2025 01:22:03 -0600

[Message part 1 (text/plain, inline)]

Severity: wishlist

The below patch makes asynchronous fontifying of man pages faster.

After typing `M-x man RET gcc-14 RET`, it takes around 5 minutes on this
fast MacBook Pro M2 (2022) machine until the whole 1.43 MiB man page is
displayed.  With a hot cache, the best time I have managed to measure is
173.432 seconds.

We seem to call `man--maybe-fontify-manpage` many times on very small
chunks: on my machine, it processes ~30 characters at a time.  Things
get substantially faster if we make `Man-bgproc-filter` fontify the
buffer in much larger chunks.  The main drawback of doing this is that
we risk very briefly seeing an incorrect display flash by in the man
buffer (e.g., with `end-of-buffer`).

My measurements show that 32 KiB might be a good choice, and gives a
~95% speedup:

| Chunk size (KiB) | Completion time (s) |
|------------------+---------------------|
|                4 |                29.3 |
|                8 |                18.2 |
|               16 |                12.7 |
|               32 |                 7.4 |
|               64 |                 6.5 |
|              128 |                 5.4 |

Is this the best approach to optimize something like this, or am I
overlooking something obvious?  Note that I didn't add a variable for
the chunk size, but we could easily add one, if that'd be useful.

When I set `Man-prefer-synchronous-call` to t, it takes ~1.8 seconds to
process the same page.  I guess that this is the lower bound for how
fast we could make the asynchronous call.

Please see the attached.

[0001-Fontify-man-page-in-32-KiB-chunks.patch (text/x-patch, attachment)]

Message #8 received at 75342 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: 75342 <at> debbugs.gnu.org
Cc: Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#75342: [PATCH] Speed up asynchronous man page fontifying
Date: Sat, 4 Jan 2025 02:12:06 -0600

[Message part 1 (text/plain, inline)]

Stefan Kangas <stefankangas <at> gmail.com> writes:

> My measurements show that 32 KiB might be a good choice, and gives a
> ~95% speedup:
>
> | Chunk size (KiB) | Completion time (s) |
> |------------------+---------------------|
> |                4 |                29.3 |
> |                8 |                18.2 |
> |               16 |                12.7 |
> |               32 |                 7.4 |
> |               64 |                 6.5 |
> |              128 |                 5.4 |

BTW, to reproduce these measurements, try the attached.

[0001-Report-time-to-process-man-page.patch (text/x-patch, attachment)]

Message #11 received at 75342 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 75342 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#75342: [PATCH] Speed up asynchronous man page fontifying
Date: Sat, 04 Jan 2025 10:27:29 +0200

> Cc: Juri Linkov <juri <at> linkov.net>
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sat, 4 Jan 2025 01:22:03 -0600
> 
> We seem to call `man--maybe-fontify-manpage` many times on very small
> chunks: on my machine, it processes ~30 characters at a time.  Things
> get substantially faster if we make `Man-bgproc-filter` fontify the
> buffer in much larger chunks.  The main drawback of doing this is that
> we risk very briefly seeing an incorrect display flash by in the man
> buffer (e.g., with `end-of-buffer`).

Man-bgproc-filter also affects how we process sections of the man
page, see bug#36927.  Wouldn't larger chunks increase the probability
of making an error there?

> My measurements show that 32 KiB might be a good choice, and gives a
> ~95% speedup:
> 
> | Chunk size (KiB) | Completion time (s) |
> |------------------+---------------------|
> |                4 |                29.3 |
> |                8 |                18.2 |
> |               16 |                12.7 |
> |               32 |                 7.4 |
> |               64 |                 6.5 |
> |              128 |                 5.4 |
> 
> Is this the best approach to optimize something like this, or am I
> overlooking something obvious?  Note that I didn't add a variable for
> the chunk size, but we could easily add one, if that'd be useful.
> 
> When I set `Man-prefer-synchronous-call` to t, it takes ~1.8 seconds to
> process the same page.  I guess that this is the lower bound for how
> fast we could make the asynchronous call.

Why not make Man-prefer-synchronous-call t by default, then?

Message #14 received at 75342 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75342 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>,
 juri <at> linkov.net
Subject: Re: bug#75342: [PATCH] Speed up asynchronous man page fontifying
Date: Sat, 04 Jan 2025 11:33:18 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> My measurements show that 32 KiB might be a good choice, and gives a
>> ~95% speedup:
>> 
>> | Chunk size (KiB) | Completion time (s) |
>> |------------------+---------------------|
>> |                4 |                29.3 |
>> |                8 |                18.2 |
>> |               16 |                12.7 |
>> |               32 |                 7.4 |
>> |               64 |                 6.5 |
>> |              128 |                 5.4 |
>> 
>> Is this the best approach to optimize something like this, or am I
>> overlooking something obvious?  Note that I didn't add a variable for
>> the chunk size, but we could easily add one, if that'd be useful.
>> 
>> When I set `Man-prefer-synchronous-call` to t, it takes ~1.8 seconds to
>> process the same page.  I guess that this is the lower bound for how
>> fast we could make the asynchronous call.
>
> Why not make Man-prefer-synchronous-call t by default, then?

The call might take longer on slower machines (or network connections)
and then block Emacs until the call was done.

Never block ui unless you can do avoid it.

Message #17 received at 75342 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 75342 <at> debbugs.gnu.org, stefankangas <at> gmail.com, juri <at> linkov.net
Subject: Re: bug#75342: [PATCH] Speed up asynchronous man page fontifying
Date: Sat, 04 Jan 2025 12:03:47 +0200

> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: Stefan Kangas <stefankangas <at> gmail.com>,  75342 <at> debbugs.gnu.org,
>   juri <at> linkov.net
> Date: Sat, 04 Jan 2025 11:33:18 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> When I set `Man-prefer-synchronous-call` to t, it takes ~1.8 seconds to
> >> process the same page.  I guess that this is the lower bound for how
> >> fast we could make the asynchronous call.
> >
> > Why not make Man-prefer-synchronous-call t by default, then?
> 
> The call might take longer on slower machines (or network connections)
> and then block Emacs until the call was done.

Slower connections (I'm guessing you mean remote man pages?) could be
recognized exempted from synchronous operation.  As for slower
machines: this is a defcustom, so users of slower machines can
customize it if the synchronous formatting is too long for them.

> Never block ui unless you can do avoid it.

Except that this comes at a price here: the time until I can see the
full man page could be very long.  So this is not a back-and-white
situation.

Message #20 received at 75342 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 75342 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#75342: [PATCH] Speed up asynchronous man page fontifying
Date: Sat, 04 Jan 2025 23:04:46 +0200

I tried the patch on OpenSUSE Linux:
- with patch: gcc-14 man page formatted [in 12.790 seconds]
- without patch: gcc-14 man page formatted [in 24.272 seconds]

Man-prefer-synchronous-call t: gcc-14 man page formatted [in 0.559 seconds]

I was surprised how fast the synchronous formatting was. Why is the
asynchronous operating so slow?

Message #23 received at 75342 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75342 <at> debbugs.gnu.org, stefankangas <at> gmail.com, juri <at> linkov.net
Subject: Re: bug#75342: [PATCH] Speed up asynchronous man page fontifying
Date: Sat, 04 Jan 2025 23:13:06 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: Stefan Kangas <stefankangas <at> gmail.com>,  75342 <at> debbugs.gnu.org,
>>   juri <at> linkov.net
>> Date: Sat, 04 Jan 2025 11:33:18 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> When I set `Man-prefer-synchronous-call` to t, it takes ~1.8 seconds to
>> >> process the same page.  I guess that this is the lower bound for how
>> >> fast we could make the asynchronous call.
>> >
>> > Why not make Man-prefer-synchronous-call t by default, then?
>> 
>> The call might take longer on slower machines (or network connections)
>> and then block Emacs until the call was done.
>
> Slower connections (I'm guessing you mean remote man pages?) could be
> recognized exempted from synchronous operation.

Yeah that's what I meant.

> As for slower machines: this is a defcustom, so users of slower machines can
> customize it if the synchronous formatting is too long for them.

I don't know yes its customizable but it could lead to some surprises.

>> Never block ui unless you can do avoid it.
>
> Except that this comes at a price here: the time until I can see the
> full man page could be very long.  So this is not a back-and-white
> situation.

Why is the price so high? The time to call man should be the same in
both asynchronous and synchronous call.

Message #26 received at 75342 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 75342 <at> debbugs.gnu.org, stefankangas <at> gmail.com, juri <at> linkov.net
Subject: Re: bug#75342: [PATCH] Speed up asynchronous man page fontifying
Date: Sun, 05 Jan 2025 08:01:28 +0200

> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: 75342 <at> debbugs.gnu.org,  stefankangas <at> gmail.com,  juri <at> linkov.net
> Date: Sat, 04 Jan 2025 23:13:06 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Never block ui unless you can do avoid it.
> >
> > Except that this comes at a price here: the time until I can see the
> > full man page could be very long.  So this is not a back-and-white
> > situation.
> 
> Why is the price so high? The time to call man should be the same in
> both asynchronous and synchronous call.

I think Stefan explained that: we read the text in small chunks, and
each chunk we read requires non-trivial processing, see the filter
function.

Message #29 received at 75342 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 75342 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#75342: [PATCH] Speed up asynchronous man page fontifying
Date: Thu, 09 Jan 2025 20:39:54 +0200

> I tried the patch on OpenSUSE Linux:
> - with patch: gcc-14 man page formatted [in 12.790 seconds]
> - without patch: gcc-14 man page formatted [in 24.272 seconds]
>
> Man-prefer-synchronous-call t: gcc-14 man page formatted [in 0.559 seconds]
>
> I was surprised how fast the synchronous formatting was. Why is the
> asynchronous operating so slow?

Maybe it performs full redisplay after processing every small chunk?
When the synchronous formatting is so fast, it makes sense to enable
Man-prefer-synchronous-call by default.  By speed up asynchronous
would be nice in any case regardless of the default value.

Message #32 received at 75342 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: 75342 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#75342: [PATCH] Speed up asynchronous man page fontifying
Date: Fri, 10 Jan 2025 16:36:36 +0200

Juri Linkov <juri <at> linkov.net> writes:

>> I tried the patch on OpenSUSE Linux:
>> - with patch: gcc-14 man page formatted [in 12.790 seconds]
>> - without patch: gcc-14 man page formatted [in 24.272 seconds]
>>
>> Man-prefer-synchronous-call t: gcc-14 man page formatted [in 0.559 seconds]
>>
>> I was surprised how fast the synchronous formatting was. Why is the
>> asynchronous operating so slow?
>
> Maybe it performs full redisplay after processing every small chunk?
> When the synchronous formatting is so fast, it makes sense to enable
> Man-prefer-synchronous-call by default.  By speed up asynchronous
> would be nice in any case regardless of the default value.

Can we disable or delay redisplay during processing of every chunk?

Message #35 received at 75342 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 75342 <at> debbugs.gnu.org, stefankangas <at> gmail.com, juri <at> linkov.net
Subject: Re: bug#75342: [PATCH] Speed up asynchronous man page fontifying
Date: Fri, 10 Jan 2025 20:40:12 +0200

> Cc: 75342 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
> Date: Fri, 10 Jan 2025 16:36:36 +0200
> From:  Björn Bidar via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Juri Linkov <juri <at> linkov.net> writes:
> 
> >> I tried the patch on OpenSUSE Linux:
> >> - with patch: gcc-14 man page formatted [in 12.790 seconds]
> >> - without patch: gcc-14 man page formatted [in 24.272 seconds]
> >>
> >> Man-prefer-synchronous-call t: gcc-14 man page formatted [in 0.559 seconds]
> >>
> >> I was surprised how fast the synchronous formatting was. Why is the
> >> asynchronous operating so slow?
> >
> > Maybe it performs full redisplay after processing every small chunk?
> > When the synchronous formatting is so fast, it makes sense to enable
> > Man-prefer-synchronous-call by default.  By speed up asynchronous
> > would be nice in any case regardless of the default value.
> 
> Can we disable or delay redisplay during processing of every chunk?

Are you sure it's redisplay that takes the time?  Not the repeated
processing of the same section of the man page after each small chunk
we read?

Message #38 received at 75342 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>,
 Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 75342 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#75342: [PATCH] Speed up asynchronous man page fontifying
Date: Fri, 10 Jan 2025 19:59:59 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 75342 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Fri, 10 Jan 2025 16:36:36 +0200
>> From:  Björn Bidar via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> Juri Linkov <juri <at> linkov.net> writes:
>>
>> >> I tried the patch on OpenSUSE Linux:
>> >> - with patch: gcc-14 man page formatted [in 12.790 seconds]
>> >> - without patch: gcc-14 man page formatted [in 24.272 seconds]
>> >>
>> >> Man-prefer-synchronous-call t: gcc-14 man page formatted [in 0.559 seconds]
>> >>
>> >> I was surprised how fast the synchronous formatting was. Why is the
>> >> asynchronous operating so slow?
>> >
>> > Maybe it performs full redisplay after processing every small chunk?
>> > When the synchronous formatting is so fast, it makes sense to enable
>> > Man-prefer-synchronous-call by default.  By speed up asynchronous
>> > would be nice in any case regardless of the default value.
>>
>> Can we disable or delay redisplay during processing of every chunk?
>
> Are you sure it's redisplay that takes the time?  Not the repeated
> processing of the same section of the man page after each small chunk
> we read?

My benchmarking suggests that it's due to the repeated processing,
indeed.  You can see this effect by removing the bug fix for Bug#36927
on top of my most recent patch, which all but removes the performance
regression for the asynchronous case.

Previous Next

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