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.
> > I have looked for other differences in xspara.c between Texinfo 7.0.3
> > and Texinfo 7.1 and cannot really see anything suspicious.
>
> XSParagraph inscludes other source files in addition to xspara.c --
> could the changes in those other files be the cause?
There are hardly any changes in these files (text.c, text.h). ppport.h
is identical (and not written by us). perl.h and XSUB.h are not included
with the Texinfo distribution.
XSParagraph.xs only changes slightly. There is a new XSUB 'xspara_counter'
which is called in one place in Plaintext.pm (and the implementation of which
is trivial).
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.
> > The only other thing that comes to mind that there could have been a
> > change in imported gnulib modules.
Running "git log gnulib/m4/gnulib-cache.m4" under tp/Texinfo/XS reveals
several new gnulib modules that have been added since the 7.0.* branch
(in the period from 2023-11-07 to 2023-10-18) but it's hard to see if
any of those could be responsible.
> >
> > Failing that, the only I idea I have is to use some kind of source-level
> > profiler to find out why so much time is spent in this module.
>
> Hmm...
