I had spent a short amount of time profiling the application some months ago. By all indications, the framework upon which the site was built was doing something really stupid.
[...] For somebody who is comfortable finding and fixing hotspots like this, it sounds like a dream come true. Not so. A quick grep through the code indicated that that particular hotspot existed in at least a dozen different points in the code base. As my role in this scenario was an ops. engineer, touching the client’s codebase was a no-no.
He first looked into something he could add at the Zend Engine level itself but then veered more towards custom functionality that overrides some base64 handling in the language. There were some difficulties following this path so he shifted to another tactic - using runkit. He implemented this "monkey patching" solution using the runkit handling and integrated it into his client's installation reducing the load time by about 10 seconds on the largest, slowest request he could find. He also includes a link to the code if you're interested in seeing how he accomplished this optimization.