While running some tests on my local machine, I discovered a certain content item on Authware took between 2.5 and 2.9 seconds to load — when nearly every other one got loaded in less than 0.7 seconds. There were some basic references to clone — especially when determining the book name for a certain content item and discovering the book was it’s own parent — and I
naturally erroneously assumed the overhead arose in those sections. Doing a manual copy of all the elements I needed instead of cloning changed nothing.
Something about code profiling from George Schlossnagle’s Advanced PHP Programming came back to me, and the hunt began. I must have been typing in the wrong stuff because only commercial products kept coming back until I got a Sitepoint article on XDebug.
Downloaded it, got WinCacheGrind and spotted the problem in less than a minute. That ‘nifty’ html_2_xhtml function I wrote sometime before when I was just starting out with regular expressions did a lot of arcane stuff with the e modifier of preg_replace.
Solution: swipe the wpautop and wptexturize functions from WordPress. The slow content item runs in less than 0.6 seconds now, and the other items take between 0.1 and 0.3 seconds to process. And er, the PHP website warns about using strstr just to determine if a needle exists in the haystack. Replacing it with strpos in my own version of wptexturize saw an increase in response times (by about 17 milliseconds).
Let’s hope I don’t keep profiling away instead of doing some real coding in the next few weeks.