Re: bad makeinfo slowdown

[Patrice Dumas]

Hello,

I uploaded the profiling information for the Parser here:
http://pertusus.free.fr/nytprof/

On Mon, Nov 08, 2010 at 04:12:50AM -0500, Eli Zaretskii wrote:
> 
> If somebody wants to be serious about speeding up the new
> implementation, then this assumption should be verified and backed up
> by profiling, IMO.  

Indeed, right now, profiling hasn't been the priority.  Having a Parser
that leads to a correct tree in every cases, including wrong Texinfo
was the priority.  So everything about speeding up is more on the side
of guesses than on the side of verified facts.

The next priority is not the profiling and speed either, it is the 
converters that have to be partly re-done to process the tree.
Next will be writing a command that uses the modules.

> Unless Perl implementation of string comparison is
> 50 times slower than C, I would be hard pressed to believe that using
> Perl is the main reason for the slowdown.  Because the original C
> implementation of makeinfo did little except comparing fixed strings
> and walking in-memory strings character by character, for the
> "parsing" part.

In fact, regular expressions are used in the Parser, instead of 
string parsing, this could be slower than using directly the strings.
But parsing is not only what you describe, one has to know a bit about
the context to do the right thing, that may be slower in perl.

Also, if you look at the profiling information I put on 

 http://pertusus.free.fr/nytprof/

you'll see that perl takes a lot of time doing things that would be 
instantaneous in C.  Structs are hash tables, there is no direct access 
to memory so a lot has to be duplicated, and it is interpreted.

That being said, it may be than the Parser could be speed up by using
the same algorithm than makeinfo in C uses for parsing, and also maybe
the style of the perl code is far from optimal from a speed point of 
view.  I haven't looked at that.


If people are interesting in speeding up the Parser, including rewriting
it in another language, I think it possible now, though documentation is 
in the form of the test suite and the matching results right now which 
is certainly far from easy to dig in.  But I don't intend to change the 
Parser or the tree, and unit test coverage should be quite good.

-- 
Pat