4 ms·

Same here, I left PHP during the early 5.x releases. Unfortunately, I inherited some Symfony applications recently. Unfortunately, because the whole stack is te

Same here, I left PHP during the early 5.x releases. Unfortunately, I inherited some Symfony applications recently. Unfortunately, because the whole stack is terribly slow and held together by an insane amount of YAML and XML configuration files. Add "annotations" (that are parsed out of doc blocks and compiled into another bunch of PHP files) to the soup and party like it's 1998. That pile of classes you end up with will serve quite some traffic behind a good caching layer, typically in the shape of a well configured Varnish instance. Needless to say that runnig this on your own machine during development will not exactly give you the excitement of working on a fast, modern platform. Rest assured, "print_r() and die()" is still a thing. Besides that, memory management is mediocre; just DON'T do long running processes with PHP. You want to enable a module? Good luck finding the right php.ini. Keeping a persistent connection pool to a database or similar is generally hard and intransparent, due to the fact that each instance serves exactly one request, but hey, at least PHP "automatically recovers" from errors... I left for good.

Revisor 9y ago
> Unfortunately, I inherited some Symfony applications recently. Unfortunately, because the whole stack is terribly slow and held together by an insane amount of YAML and XML configuration files. Add "annotations" (that are parsed out of doc blocks and compiled into another bunch of PHP files) to the soup and party like it's 1998. That sounds like a wrong configuration and/or architecture. Symfony is in my experience fast if you follow the best practices. Maybe you should find out the bottlenecks before you blame Symfony. > just DON'T do long running processes with PHP. We run long-running workers just fine. > You want to enable a module? Good luck finding the right php.ini. That depends on your OS. In Debian/Ubuntu you just run phpenmod module and restart the service. I don't know... Your criticism seems to stem from not looking at the issues closely, or maybe you were stuck in a really old, abandoned system. But that woukd have been ugly regardless of language.
tgalopin 9y ago
I guess your comment wasn't written to be answered, but please note that the lack of validity of your arguments prove how badly you know PHP. In the En Marche platform project, we serve million of users per month, with fast response times, deployment without downtime, 4 mail workers and multiple PHP instances in paralell synchronizing cache using Redis. I personally worked on several projects having the same infrastructure and the same high quality standards. I think that, as many other developers, you have a strong but irrationnal opinion on PHP and will do everything in your power to attack it. I hope this kind of behavior will fade in the future, as it should not represent our community.

Revisor 9y ago

> Unfortunately, I inherited some Symfony applications recently. Unfortunately, because the whole stack is terribly slow and held together by an insane amount of YAML and XML configuration files. Add "annotations" (that are parsed out of doc blocks and compiled into another bunch of PHP files) to the soup and party like it's 1998. That sounds like a wrong configuration and/or architecture. Symfony is in my experience fast if you follow the best practices. Maybe you should find out the bottlenecks before you blame Symfony. > just DON'T do long running processes with PHP. We run long-running workers just fine. > You want to enable a module? Good luck finding the right php.ini. That depends on your OS. In Debian/Ubuntu you just run phpenmod module and restart the service. I don't know... Your criticism seems to stem from not looking at the issues closely, or maybe you were stuck in a really old, abandoned system. But that woukd have been ugly regardless of language.

tgalopin 9y ago

I guess your comment wasn't written to be answered, but please note that the lack of validity of your arguments prove how badly you know PHP. In the En Marche platform project, we serve million of users per month, with fast response times, deployment without downtime, 4 mail workers and multiple PHP instances in paralell synchronizing cache using Redis. I personally worked on several projects having the same infrastructure and the same high quality standards. I think that, as many other developers, you have a strong but irrationnal opinion on PHP and will do everything in your power to attack it. I hope this kind of behavior will fade in the future, as it should not represent our community.