Re: Post release texi2any performance regression

[Gavin Smith]

On Thu, Oct 26, 2023 at 12:13:10AM +0200, Patrice Dumas wrote:
> > Can I please propose that it is made easy to disable all new XS code
> > in texi2any, as I have done here, so we can avoid losing the performance
> > of texi2any 7.1.  I don't really care how it's done, as long as TEXINFO_XS
> > and TEXINFO_XS_PARSER work as before (so TEXINFO_XS_PARSER should be limited
> > to turning off the XS parser).  It could be configured with a new variable
> > TEXINFO_XS_MISC or TEXINFO_XS_NEW, or depend on TEXINFO_XS_CONVERT.
> > 
> > It worries me that the new code is entwined with the program and hard to
> > disable, and could lead to permanent slowdowns if the work doesn't proceed
> > as hoped.  It would seem much safer for the development of the program
> > to separate it and be able to disable it cleanly.
> 
> It is probably not so difficult to do, but I think that we should not.
> First, I can't see a concrete situation where the combination of
> TEXINFO_XS_PARSER and not TEXINFO_XS_MISC should never be used by users,
> it would only be possibly interesting for development or timing (the
> combination of not TEXINFO_XS_PARSER and TEXINFO_XS_MISC is not
> possible).  Second, it makes yet another combination to test during
> development, which I think is too much work for little gain.  We already
> do not test much some combinations, for instance I guess that
> TEXINFO_XS_PARSER=0 is almost never tested.  There will already be more
> combinations with TEXINFO_XS_CONVERT set or not, adding more seems
> to me to be useless.  And lastly, the comparison of TEXINFO_XS_MISC and
> not TEXINFO_XS_MISC does not seem to be that useful for development to
> me, as we cannot gain much insight on what to do based on those
> comparisons of perl code and C code, what is interesting would
> be to improve each of these codes, be it for timing or anything else.

I can see the issue with having too many environment variables but the
fact remains that the program is slower than it used to be, with no
clear sign that this slowdown will ever be reversed.

I will try to propose a change myself once I can work out how to
get the test suite to pass.

> For timing optimization, it seems to me that we should have only one
> target, the combination were everything is done in XS.  To me there is
> little point in trying to optimize other combinations, because they are
> very unlikely to be used.  The only other combination I can imagine to
> be used is the perl only combination triggered by TEXINFO_XS=omit that
> could be used to workaround a bug in the full XS combination at the cost
> of performance.

What about the case of when an XS converter hasn't been written yet?