[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bad makeinfo slowdown
From: |
Patrice Dumas |
Subject: |
Re: bad makeinfo slowdown |
Date: |
Mon, 8 Nov 2010 12:30:59 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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
- bad makeinfo slowdown, Per Bothner, 2010/11/06
- Re: bad makeinfo slowdown, Karl Berry, 2010/11/06
- Re: bad makeinfo slowdown, Per Bothner, 2010/11/07
- Re: bad makeinfo slowdown, Patrice Dumas, 2010/11/07
- Re: bad makeinfo slowdown, Karl Berry, 2010/11/07
- Re: bad makeinfo slowdown, Per Bothner, 2010/11/07
- Re: bad makeinfo slowdown, Patrice Dumas, 2010/11/08
- Re: bad makeinfo slowdown, Eli Zaretskii, 2010/11/08
- Re: bad makeinfo slowdown,
Patrice Dumas <=
- Re: bad makeinfo slowdown, Werner LEMBERG, 2010/11/08
- Re: bad makeinfo slowdown, Werner LEMBERG, 2010/11/08
- Re: bad makeinfo slowdown, Karl Berry, 2010/11/08
Re: bad makeinfo slowdown, Patrice Dumas, 2010/11/07