You would think the frameworks would be designed around that, loading the absolute minimum of code to handle the request.

That still doesn't prevent you from needing to do that on each request.

Also, with most frameworks, they're usually quite complex; how else are you going to be everything for everyone? Complexity comes at a cost, most notably in framework land this takes the form of code with very tall inheritance structures and/or tons of dependencies.

You need Foo? Ok, Foo inherits from BaseFoo, which inherits from CoreBaseFoo, which inherits from the Widget class, which itself is a BaseWidget, etc. Let's implement a few interfaces too, and now load in various dependencies... pretty soon that simple, 5-line class that you implemented now requires 100+ classes.

Things like op-code caching can greatly reduce this per-request penalty, but it doesn't change the fact that it still happens.

Except that nothing says that you need deep class hierarchies. In fact, i think heavy use of classes and class hierarchies is an anti-pattern in PHP because of its procedural per-request model.

Typically php frameworks follow a java-style model of unserializing data into objects, loading the corresponding class files on-demand, calling API's on the objects, and then reserializing. It is _much_ faster if you treat the data as a stream, cutting it up and transforming it as it passes through your code, without ever building up an object representation, and not doing any more deserialization than a simple json_decode (which is really fast). This is in fact the original PHP model, transforming a stream of annotated HTML.

Lazy Loading is a thing with modern PHP frameworks.

I'll give an example: zend_validate uses a proper OO hierarchy, so that for each type of validation (maxlength, digits, ...) there's a distinct validator class, which has to be instantiated prior to being applied to a piece of data. The whole thing is really clean and organized ... and abysmally slow, because on each request you're loading dozens of validator classes. That would have been much faster had it been a simple ugly procedural API with all its code in one file. The per-request overhead of input validation is more important than a 'pure' oo design in my opinion.