Hacker News Reader

Comment by cmircea | Hacker News Reader

Probably because all those big frameworks have to initialize everything for every request. Parsing, connections, configuration, you name it.

View on HN

Yeah, of course.

With slim in particular I notice that the benchmarks list it as "Raw database connectivity" but in the code it looks like it's using RedBean ORM. I'll look more at lunch, i'm probably just misreading something.

Although obviously ORM is more realistic, since if you're sophisticated enough to be using composer and a framework, you're probably using an ORM. I know the point of this benchmark is frameworks not ORMs, but it would be interesting to swap them out and see if there's a huge difference.

Raw php also has to initialize connections, and it does really well, so I don't think that's it. To me, that points to overhead from initializing the objects as the bottleneck. I would have thought that with APC, this wouldn't be a major issue, though, so I wonder if that's still not it.

APC only caches the opcodes, so the interpreter doesn't have to parse your code. But the framework still has to set up itself for each request individually. Parse configuration, create objects, etc. It adds up quickly.

I always hear this myth that php gets very slow when you write proper OO code. I neither write nor maintain any php code so I wouldn't know.

Is there no php environment with a persistent server? Are they really all doing per request startup?

Yes. The PHP process keeps running but resets completely on every request. The bytecode is cached though, so loading the code shouldn't add much overhead.

PHP can be used for long-running jobs, but it doesn't have very good garbage collection, and has no language-level concurrency and very little asynchronicity.

Well, you could daemonize a PHP process, which would listen to some port, and parse the requests. It's like implementing your web server in PHP.

The problem with it is, one request can bring the whole thing down.

Reply on news.ycombinator.com