On Sun, Nov 05, 2023 at 11:59:11AM +0100, Patrice Dumas wrote:
> On Sat, Nov 04, 2023 at 04:06:05PM +, Gavin Smith wrote:
> > > At that point, using a new env variable to use perl for
> > > structuring/transformations would be very easy based on your patch.
> > > If you give a name, I can do it
On Sun, Nov 05, 2023 at 01:01:21PM +0100, Patrice Dumas wrote:
> > Indeed, commenting out those lines of code (although it makes the output
> > incorrect) appeared to restore the run time to that of 7.1.
> >
> > This may have been due to a fairly recent change, but the lack of a
> > stable, satisf
On Sat, Nov 04, 2023 at 11:18:59PM +, Gavin Smith wrote:
> After comparing results from NYTProf for Texinfo 7.1 and the master
> branch with the patch I posted, the remaining possibility that I suspect,
> but which I haven't been able to investigate yet due to being stymied
> by other problems,
On Sat, Nov 04, 2023 at 06:53:34PM +, Gavin Smith wrote:
> On Sat, Nov 04, 2023 at 04:06:06PM +, 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 investiga
On Sat, Nov 04, 2023 at 04:06:05PM +, Gavin Smith wrote:
> > At that point, using a new env variable to use perl for
> > structuring/transformations would be very easy based on your patch.
> > If you give a name, I can do it.
>
> Would TEXINFO_XS_STRUCTURE be ok?
Should be done in
https://git
On Sat, Nov 04, 2023 at 04:06:06PM +, Gavin Smith wrote:
> > > Applying this patch slows the program down by about 3% now. However,
> > > it could still be useful for investigating why development texi2any is
> > > still significantly slower (about 5%) than texi2any 7.1. It seems that
> > > e
On Sat, Nov 04, 2023 at 04:06:06PM +, 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 dif
On Sat, Nov 04, 2023 at 02:50:36PM +0100, Patrice Dumas wrote:
> On Sat, Nov 04, 2023 at 01:18:58PM +, Gavin Smith wrote:
> > On Sat, Oct 28, 2023 at 05:42:51PM +0100, Gavin Smith wrote:
> > > I managed to disable a lot of the new XS code and get the test suite
> > > to pass. I had to leave th
On Sat, Nov 04, 2023 at 01:18:58PM +, Gavin Smith wrote:
> On Sat, Oct 28, 2023 at 05:42:51PM +0100, Gavin Smith wrote:
> > I managed to disable a lot of the new XS code and get the test suite
> > to pass. I had to leave the XS translation module active due to the
> > coupling that now exists
On Sat, Oct 28, 2023 at 05:42:51PM +0100, Gavin Smith wrote:
> I managed to disable a lot of the new XS code and get the test suite
> to pass. I had to leave the XS translation module active due to the
> coupling that now exists between it and the XS parser.
This patch wasn't working any more so
On Sun, Oct 29, 2023 at 03:18:14PM +0100, Patrice Dumas wrote:
> In commit
> https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=7f1b750038f13a58bbd513a6f2f07dda5e87ad3f
> I have modified the code such that with XS the first document built
> out of the parser is a minimal document, without ind
On Wed, Oct 25, 2023 at 10:12:48PM +0100, Gavin Smith wrote:
> (Simply commenting out
>
> $document = Texinfo::Structuring::rebuild_document($document);
>
> improved run times dramatically, but gave incorrect output without
> disabling the other XS code.)
In commit
https://git.savannah.gnu.org/c
On Sat, Oct 28, 2023 at 05:42:50PM +0100, Gavin Smith wrote:
> I managed to disable a lot of the new XS code and get the test suite
> to pass. I had to leave the XS translation module active due to the
> coupling that now exists between it and the XS parser.
Also I doubt that any slowdown could c
On Sat, Oct 28, 2023 at 11:15:36AM +0200, Patrice Dumas wrote:
> > At the moment, performance improvements from the new code seem
> > hypothetical.
>
> Actually, my guess was that there would also be a performance
> improvement with the XS overrides of parser
> post-processing/Structuring/Transfor
On Fri, Oct 27, 2023 at 11:57:12AM +0100, Gavin Smith wrote:
>
> I wasn't talking about whether they would work or not, I was talking about
> how fast they would run.
Ok.
> At the moment, performance improvements from the new code seem hypothetical.
Actually, my guess was that there would also
On Fri, Oct 27, 2023 at 01:22:01AM +0200, Patrice Dumas wrote:
> On Thu, Oct 26, 2023 at 06:45:10PM +0100, Gavin Smith wrote:
> >
> > > 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 poi
On Thu, Oct 26, 2023 at 06:45:10PM +0100, Gavin Smith wrote:
>
> > 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 un
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
On Wed, Oct 25, 2023 at 10:12:48PM +0100, Gavin Smith wrote:
> On Tue, Oct 24, 2023 at 06:15:06PM +0200, Patrice Dumas wrote:
> There still seems to be lacking any way to turn off the new XS code that
> is being run, in order to judge the performance impact. TEXINFO_XS_PARSER
> is now used for a l
On Tue, Oct 24, 2023 at 06:15:06PM +0200, Patrice Dumas wrote:
> Maybe it is because of the C code that is run in parallel with perl code?
> That would be my first guess. Hopefully, the default will be not to run
> C and perl in parallel for the release. Maybe you could compare with
> a run with
On Sat, Oct 21, 2023 at 07:17:32PM +0100, Gavin Smith wrote:
> Typical texi2any run times are somewhat longer now, compared with the
> last released version ("time" output below) - roughly 5% longer.
>
> Any idea what's responsible for the longer run times? At what point
> with the new code did t
Typical texi2any run times are somewhat longer now, compared with the
last released version ("time" output below) - roughly 5% longer.
Any idea what's responsible for the longer run times? At what point
with the new code did the performance get worse?
I've run texi2any with NYTProf both for 7.1
22 matches
Mail list logo
