[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Separate compilation: Circumventing the speed hit of Texinfo-5
From: |
Gavin Smith |
Subject: |
Re: Separate compilation: Circumventing the speed hit of Texinfo-5 |
Date: |
Thu, 11 Dec 2014 20:50:06 +0000 |
On Thu, Dec 11, 2014 at 3:45 AM, Eli Zaretskii <address@hidden> wrote:
> Perhaps the performance should be higher on the agenda than it
> evidently is.
>
> Did someone try compiling the Perl code into C?
>
Not me, does anyone know how to do that?
There is a chance for speedups with the current project to rewrite the
parser in C. The Perl implementation of makeinfo parses a Texinfo
source file into a tree-like data structure which is then further
processed to create the output files. In a test I did the parsing
stage took about a third of the total time. However, there could be
speed-ups in the other parts of the code as well (the Perl parts) if
accessing the tree via an API into the C part is faster than accessing
Perl's own data structures of hashes and arrays.
You can see the work so far in the parsetexi subdirectory of the
current SVN repository. However, I haven't been able to get it
integrated into makeinfo and work for any input Texinfo file yet. Work
so far has been slow and there may be difficulties that I haven't
encountered yet. If this can be accomplished then it would greatly
ease developing the C parser as we would be able to tell if we were
producing the parse tree correctly as the rest of the code needs it.
Since the parse tree is not actually a perfect tree (there are
references to elements in more than one place) the C code to dump the
required data structure could take some effort to write.
Currently there is a program to dump the parse tree to a text stream,
which is then read in again by Perl code. (See the
"parsetexi/Parsetexi/t/Parsetexi.t" file for the beginnings of what
this would look like.) This process is slow, and hardly produces a
speed-up at all. We also hope to produce an API in a perl XS module
that the back-ends would use to access the tree, which would be
faster. The main problem I envision with this approach is that the
Perl code might do something tricky somewhere which wouldn't be easy
to replicate with an API implemented with C.
When the Perl code is converted to use this API the API would also be
implemented by Perl code, to check the conversion was done properly.
When the C parser and API are complete this would be switched over.