Recursive parser

Thought it would make sense to open a new topic for this one.
(or does it exist already? couldn’t find one)

Looked at the new recursive parser, and it looks nice!

Found couple of issues, tried to fix them, have a look at the attached file please

Greetz,

Remon

P.S.
Attached the modified document.parser.class.inc.php instead!

A quick test run on performance.

All functions used are part of the core php distribution, thats probably the reason I can’t profile this script, other then looking at the total processing time :-(
(no profiling output generated..)

Anyway, I inserted the TP3.2 template (which is a rather large template code wise), which is of course for the strpos and friends functions not so nice.

Even with 21 snippets, the total time was just 0.010 seconds on my server (amd k6 400), so I don’t think performance is an issue here
(or in other words, no chance to improve the situation anyhow)

Of course, if I could compare it with the current logic.....

Remon

(if you don’t mind a little messy output, the parser output _does_ look nice:
http://vt.shuis.tudelft.nl/~remon/test/pseudo.php
)

Wow, this is cool stuff. 0.010 is quite a bit faster than our previous times isn’t it?

Keep up the good work. The new parser is going to be awesome!

Well, what you think.. can we beat Etomite by incorporating this ?

Then it is AWESOME ... speed is major factor

regards,

zi

Ehmmmm, this is _without_ evaluating the real snippets, hence my question "Of course, if I could compare it with the current logic....."

Also, this time is a bit misleading, cause it doesn’t count for the time spent in the webserver etc.

With apachebench, the part of the parser which _replaces_ the snippet tags consumes as much time that my server can serve 33 requests per second.

The current complete parser, which does a little more (perhaps a lot more) consumes as much time that my server can serve ~ 10 requests per second.

Now the question is, how much does the other logic add to the parsing time.... ;-)

Remon

Very nice work Remon.

It would be very nice if we can get this parser to perform better than the current logic.

So can we now take Remon’s tweaked parser and add in the current relevant snippet/chunk/template/etc. stuff to see how it performs against the current methods?

Quote from: rthrash at Nov 14, 2005, 11:20 AM

So can we now take Remon’s tweaked parser and add in the current relevant snippet/chunk/template/etc. stuff to see how it performs against the current methods?

There is a whole lot done in the current parser. The recursive routine provided by Raymond is only part of all the work done by the current parser, but I hope to see if I can extract the part similar to the recursive thing, and see what the differences are. (I guess, it’s a comparison between the recursive function versus preg_match_all)

Now I first need to do the dishes

Remon

Hmmm,

I’m not sure how the recursive parser will support [**], [++], [[]], etc but it was design for the [[]] syntax.

True. Well... Maybe we can start inserting the snippet/chunk/template/etc. logic in the parser loop to get some tests with real examples.

Even with the extra step of Regex’ing the old style calls into the new style, I bet’ it’s faster still!