document.parser.inc.php code size

If someone has something in mind, he/she has to write it down, so here it is ;-)

Currently, the document.parser.etc is about 2400 lines of code.

I thought, it would be nice to clean it up, group function into classes, and only include those classes when needed...

So, I stripped down the parser in such way it still kept working on the default install of modx (I think I also stripped down some parts of the webuser functionallity, just removed functions until a parse error occured)

So, the stripped down parser is ~ 1600 lines of code still, and it’s interesting to see the results:
Before: 15.5 req/sec
After : 17.0 req/sec

This is on a PIII 800
EDIT: With a non-cached pages!
EDIT 2:
With the home page cached:
Before: 35.0 req/sec
After : 41.0 req/sec
:-)

Just to make sure it makes sense to strip down the parser, and move the functionality in seperate files which only have to be included when needed ;-)

Greetz,

Remon

I think this is something that we really need to do at some point. I’ve always though it was rediculous that almost everythnig is in one class. It pretty much makes the whole object oriented method useless.

Here are some of the separate classes I think we need

• Template
• Document
• TemplateVariable
• Snippet
• User

This is just off of the top of my head, I’m sure there are many others.

Here are a couple of questions related to a better OOP API too.
1. Can we overhall the API without loseing backwards compatability? If so, is it worth the effort?
2. PHP 5 has some huge OOP improvements over PHP 4. Do we want to require PHP 5 with the new API?
3. Have we thought about serializing a Document object for caching purposes? Would this be faster or slower than our current method?

My totally non-experiential guesses:

1. Can we overhall the API without loseing backwards compatability? If so, is it worth the effort?

Yes. And Yes.

2. PHP 5 has some huge OOP improvements over PHP 4. Do we want to require PHP 5 with the new API?

For 0.9.5, I don’t think so. If we were entertaining this conversation in 365 days, I’m betting 99% I’d say yes.

3. Have we thought about serializing a Document object for caching purposes? Would this be faster or slower than our current method?

No clue... test it and let’s find out!

php5 as a requirement is perhaps not good, since I don’t know when my or others hosting providers will have it installed.

But it might be a good idea to keep php5 in mind when working on this?

Also, what about a "mini" parser loading first, with only the bare minimum to check the url method, page cache, and if the page can served from cache completely, output it?
In case more has to be done (user auth., snippet eval etc) load the "rest" of the parser and continue there?

Would probably make sense, since a static served html file is still ~ 20 times faster then a cached page from modx with the stripped down parser.... :-(

That’s a very interesting idea Remon. The mini-processor (or pre-processor) could also do the work of converting legacy API calls, or if we decide to really clean up the processor as you suggested and deprecate some API calls, include the file if it’s needed. Lots of options there.

Quote from: R.S. at Nov 16, 2005, 07:59 AM

Also, what about a "mini" parser loading first, with only the bare minimum to check the url method, page cache, and if the page can served from cache completely, output it?

Yes definitely! Let’s only load up what we need to get the job done.

I would like to make a couple point here:
. Even though php5 is not available yet but it is good to code against php5 to get a better coding standard and take out most warning. In my own project before I start using php5 I have no idea there were so many warning and my apps still run, it is amazing!, but now I test my apps with php5 and take out all the warning and the apps are better and faster in general so as long as we don’t use php5 specific that cause it not to run in php4
. A "mini" or "Pre-parses" is an excelent idea! For example for site that only need to do a very simple pages no fancy stuff then there is no need for the parser to do any work. So a "Pre-parser" will be great to make a determination on whether it should dig deeper or not. Thus will greatly improve the performance.
. Break the parser into seaprate class and load it when it is need also is a great idea and will certain improve the performance.

Everyone has done a great job so far in regarding improving the parser.

Thanks for the good work!

Quote from: chanh at Nov 16, 2005, 08:27 AM

I would like to make a couple point here:
. Even though php5 is not available yet but it is good to code against php5 to get a better coding standard and take out most warning.  In my own project before I start using php5 I have no idea there were so many warning and my apps still run, it is amazing!, but now I test my apps with php5 and take out all the warning and the apps are better and faster in general so as long as we don’t use php5 specific that cause it not to run in php4

Very good point!

But php4 also has a callback function for warnings, so.....

And indeed, coders should test their code with all warnigns set to on to fully debug their code. I also find it amazing php keeps running with IMO grave bugs!

Hmmm,

I don’t think it’s a good idea to break compatibility with php4 and early versions of MODx. We need to find a way to get the best of both worlds.

On the issue of breaking up the parser... This would seems to be a nice thing to do un the surface but what will happen to a page that requires all those parts of the parser? Remember that included files depends on disk I/O which is very slow. Some recent tests showed that having multiple include files could slow performance.

Quote from: xwisdom at Nov 16, 2005, 08:56 AM

Some recent tests showed that having multiple include files could slow performance.

Yes but you can still have multiple objects defined in one file too, or break each class into it’s own file, whichever is faster in general. Either way I think we should have more consolidated objects to get the advantages of an purer OO structure.