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
