a discussion
You can fairly accurately profile berylium by tacking debug=1&profile=1 onto the end of a URL. What you get is a big page full of all the standard debugging messages, each one with a timestamp. On recent passes, I've found a couple areas that need attention this way. getimagesize() is a primary offender!
Getimagesize() is taking up to 0.4 seconds per call, which isn't pretty when you have 11 calls to render a single page. Why is it so slow? Anyway, we need to store correct image size data in the database so getimagesize() is only called when the image changes (say, after a resize operation). It used to be this way, then I got lazy and made it dynamic. :-(
Another big offender seems to be $this->timeFormat(), which is called by getRuntimeVars() on just about every object. Which sucks, because it's a really useful call.
The truly astounding thing, though, is to see the number of times getBaseUrl() and applyPolicy() get called on the same object-- not because they shouldn't, it's not happening redundantly. They're getting called on different instances of the same object (eg, sitemember 93 is the author of six different documents, so we end up reprocessing sitemember 93 six times when it could be once.)
There needs to be some sort of object lookup table that can be checked against, and allow us to duplicate known objects instead of building them from scratch.
Also, policies are back out of control, and all I wanted to do was make every item aware of whether the current sitemember was an owner and/or editor of that object, not parse the policy file afresh on each call.
By Chris Snyder on January 28, 2003 at 11:07pm