texinfo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performance profiling of makeinfo


From: Gavin Smith
Subject: Re: Performance profiling of makeinfo
Date: Thu, 8 Jan 2015 10:55:11 +0000

On Fri, Dec 26, 2014 at 8:27 PM, Patrice Dumas <address@hidden> wrote:
> Indeed, that's the reason.  Oddly in my tests there wasn't that much use
> of gdt, but I can imagine that in some case gdt could be called a lot.
> There is a potential of good acceleration here.  In general the parser
> is reused, but in gdt, there is comment explaining why it is not a good
> idea:
>   # Don't reuse the current parser itself, as (tested) the parsing goes
>   # wrong, certainly because the parsed text can affect the parser
>   # state.
> So a secondary parser is used, which means that all what is done
> regarding indices/nodes/sections... is forgotten when going out of gdt,
> and in any case in gdt there should be no such Texinfo code, it is only
> for strings to be translated.  So, I think that a better course of
> action would be to have a way to define a parser setting only a subset
> of parser options, and defining differently some keys, instead of
> copying simply passing references as they are not supposed to be
> modified in the code in gdt.
>
> I could propose something in the next days.
>
> Also, I suppose we could use dclone or something else in any case.

The changes you made gave a good speed-up for the elisp.texi manual.
Testing with the texi2any in the texinfo 5.2 release, it runs in about
1 min 38 sec on my computer (user time, reported by the "time"
command). (I had to run "./texi2any.pl" in the source directory to get
the right modules. ) Testing with the latest version from the
repository, this comes down to about 48 seconds.

With the XS reimplementation of Paragraph.pm (which is not complete
yet), the time comes down to about 35 seconds. I'd propose leaving
integrating this until after the next release, because I don't know
how long it will take to complete, and it will likely cause problems,
expected and unexpected.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]