Re: Post release texi2any performance regression

[Patrice Dumas]

On Sat, Nov 04, 2023 at 06:53:34PM +0000, Gavin Smith wrote:
> On Sat, Nov 04, 2023 at 04:06:06PM +0000, Gavin Smith wrote:
> > > To me the most likely reason would be that simple_parser has been
> > > removed, such that calls of gdt/pgdt from perl are slower.
> > 
> > Thanks, I'll try to investigate this.
> 
> This is very significant for TEXINFO_XS=omit but makes no difference
> for TEXINFO_XS=require, as I had suspected.

Indeed, I don't know why I want it to have an effect, as it should
not...

> If there is a real problem, then we could fix it another way, maybe
> by "locking" the parser configuration at certain points, making any
> changes ineffective?

There is a real problem, the state of the parsers is shared among calls
to simple_parser.  As long as in gdt code there is only simple code it
is not an issue, though, it only becomes an issue if the users put
@-commands that use the conversion state in gdt.  In that regard, the
translation_in_parser_in_translation test is quite extreme, but
@-commands modifying and needing the state are not so uncommon, it
includes commands that could be in translations, such as @acronym,
@anchor and others.

I think that the approach of having shared state is both unusual and not
correct. Another possibility, which could be better and allow some gains
too would be to reuse a parser instead without initializing it.  It
would still maybe need some more cleanup of state between runs, maybe
with a separate function that would do nothing in XS, such that it does
not need to be run when the parser is not reused.  This would also
probably be more similar to what should be the final XS implementation.

> I would like to commit this, except that the
> "perl -w t/init_files_tests.t translation_in_parser_in_translation"
> test breaks.

It will break other redefinitions of translated strings.

-- 
Pat