Oh I hear that! I hate those hello world comparisons. That is an obvious bias against a language like php. The more complex the application becomes, the more level the playing surface between php and python and perl becomes. So sure php looks slow in a hello world, no database script. But as soon as you're pulling in all those libs for the other langs, I'm willing to bet the gap shrinks right on down. I would love some hard numbers on that, but AFAIK nobody has bothered to port a large, complex app between symfony, django, whatever perl offers, rails...etc.
Noel [EMAIL PROTECTED] wrote: > APC beeing bundled with PHP in future is indeed a good argument to > keep an eye on it. My point was more on those comparisons all around. > Especially those about frameworks ... ;o) where symfony is always the > worst. > > Michael > > > On Feb 27, 9:30 am, noel t <[EMAIL PROTECTED]> wrote: > >> First I'd just say that Michael here is right -- your mileage may vary. >> Do your own comparisons. But as someone who started with eaccelerator, >> tried xcache, and finally settled on APC, I'd have to vouch for APC in >> the end. My benchmarks show all three to be basically identical in >> performance. Published, informal benches on the net show xcache to be >> the #1. I had problems with xcache and symfony as symfony tries to call >> admin only functions of xcache which triggers an htauth call. That was >> with symfony 1.0b4. Not sure if xcache support was worked on since then. >> >> As far as configuration goes, eaccelerator and APC are pretty damn >> easy. Xcache has a lot more settings and not the greatest explanation >> as to what they all do. But Xcache lets you use more than 1 memory >> segment so mutli processor machines can take advantage of that (so they >> say). APC seems to allow you to use more than one segment, but the >> included tool to monitor it doesn't seem to support more than one. >> AFAIK, eaccelerator only uses one segment. >> >> Finally I'd just like to point out as I did in an earlier post to the >> group that while performance differences between the three might be slim >> enough to be considered moot, if upgrading to the latest/greatest php >> breaks your accelerator as it did with eaccelerator when I moved to >> 5.2.1, you're going to be forced to hold back, switch while in >> production to another opcode cache, or stop using them altogether. APC >> being in PECL is an official part of php and slated for inclusion in >> php6. That is a point worth consideration I think. >> >> Noel >> >> p.s. I didn't notice much difference in memory consumption between >> eaccelerator or APC. Both consume around 16megs of RAM for our project. >> >> [EMAIL PROTECTED] wrote: >> >>> Well, >>> >>> i tried APC (disabled eA for that) and run it on my own "heavy" >>> backend. The speed numbers are almost the same (APC is still slower). >>> The memory usage however is with APC 1.6 times higher than with eA. I >>> used default settings on both accelerators ... >>> >>> I recommend to make own tests with both (any) accelerators, it's not >>> that difficult. It is much better than relay on this comparisons ... >>> >>> Michael >>> >>> On Feb 19, 5:31 pm, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: >>> >>>> Slick Rick wrote: >>>> >>>>> There is a known issue with eAccelerator and PHP 5.2 that cause infinite >>>>> loops and segfaults. I would stick with 5.1 until this is fixed. >>>>> >>>> or give pecl::APC a try .. as things stand APC has a good chance of >>>> being bundled with PHP6. >>>> >>>> regards, >>>> Lukas >>>> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
