Re: Texinfo 7.1 released

[Eli Zaretskii]

> From: Gavin Smith <gavinsmith0123@gmail.com>
> Date: Sun, 22 Oct 2023 21:01:54 +0100
> Cc: bug-texinfo@gnu.org
> 
> On Sun, Oct 22, 2023 at 10:05:16PM +0300, Eli Zaretskii wrote:
> > > This patch, applied to 7.1, removes the recently added dTHX calls,
> > > but also removes the fprintf calls that were preventing compilation
> > > without it:
> > 
> > It doesn't help: 1:20.7 instead of 1:21.2.
> 
> I'm running out of ideas.  Have you tried timing it with a smaller input
> file (e.g. doc/info-stnd.texi)?  That could detect whether the slowdown
> depends on the size of the input, or if it is a single slowdown to do
> with initialisation/shutdown.

The times seem to be roughly proportional to the size of the generated
Info file, yes.

> Another change is that xspara.c uses btowc now.  I hardly see how it makes
> a difference, but here is something to try:
> 
> diff xspara.c{.old,} -u
> --- xspara.c.old        2023-10-22 20:59:03.801498451 +0100
> +++ xspara.c    2023-10-22 20:59:29.189031067 +0100
> @@ -730,7 +730,7 @@
>                if (!strchr (end_sentence_characters
>                             after_punctuation_characters, *p))
>                  {
> -                  if (!PRINTABLE_ASCII(*p))
> +                  if (1 || !PRINTABLE_ASCII(*p))
>                      {
>                        wchar_t wc = L'\0';
>                        mbrtowc (&wc, p, len, NULL);
> @@ -1013,7 +1013,7 @@
>          }
>  
>        /************** Not a white space character. *****************/
> -      if (!PRINTABLE_ASCII(*p))
> +      if (1 || !PRINTABLE_ASCII(*p))
>          {
>            char_len = mbrtowc (&wc, p, len, NULL);
>          }
> 
> This means that all calls go via the MinGW-specific mbrtowc implementation
> in xspara.c.

Bingo.  This brings the time for producing the ELisp manual down to
15.4 sec, 5 sec faster than v7.0.3.

I see that btowc linked into the XSParagraph module is a MinGW
specific implementation, not from the Windows-standard MSVCRT (where
it is absent).  My conclusion is that the MinGW btowc is extremely
inefficient.