3.3: final preparation and performance

OK... so we’re close to ready to release... need a thorough content scrubbing on the site, then it needs to be committed to SVN. Please check it out. In the interim, if anyone has some ideas for quick speed optization bumps, time to share them now:

http://www-mirror.vet.ohio-state.edu/shootout/

I think if this test is run when the stat collection is turn on for Modx and Etomite is off then it might indicate the different. I just wonder what is the configuration of this comparision between Modx and Etomite.

Are they exactly the same as far the stat is being turn off on both?
Is there any other configuration different between the two?

Just a thought!

Also, when caching is mentioned for search results the PAGE CAN BE CACHED!!!!

The snippet call just must be [!snippet!].

I have to use this on my ulta slow server (globat.com) to keep it from becoming a snail!

I think the configs were done pretty similarly, if not identical. We’ve got a lot more going on in the parser, so that’s playing a factor, I’m sure.

Ryan,

In that case can the parser be optimized or consolidate many tag into lesser tag and use a property to distinct between different document type.

Will that speed up the parser?

Hmm...I wonder....

I wonder what would happen if we took out all references and backwards compatibility with Etomite...

Would the parser be much faster? Might be a good thing to test.

Quote from: Bravado at Oct 15, 2005, 12:08 AM

Hmm...I wonder....

I wonder what would happen if we took out all references and backwards compatibility with Etomite...

Would the parser be much faster? Might be a good thing to test.

Dunno lot about coding, but seems worthy to try

Remove un-used functionalities is always a good things but is Etomite compatiblity should be removed at this time? The fact is we just get start and more functions are in the works!

I want to offer the following recommandation in term of code optimization:

1. Try to not switch between php, javascript and html too much and use <<<EOT; convention to minimize the php engine from go in and out different mode frequently
2. Replace multiple "if" with "case/switch" whenever possible and place the most used condtion first and least used last
3. In function exit early in the code if the condition is right
4. Try to compress HTML code with ob_start("ob_gzhandler");
5. use PEAR Cache
6. Use specific select field rather than wild select
7. Turn multiple direct select connection to database to array manipulation.

Other poeple also believe minimize number of include file in php code meaning group those related function into one include file. The theory is disk I/O is slow in comparision to memory I/O.

After removing the lines that are responsible for compatibility, I ran a few tests on the two installations I have of MODx. No real difference in performance. So...guess I proved that the extra bits for Etomite compatibility have no real impact on performace.

I capture a profiling of the latest modx 3.3 trunk from SVN for your amusement!

For you Modx experts these number might mean more to you than me.

Please let me know what you think.

Thanks