Robert Cummings wrote: > > > Martin Zvarík wrote: >> Ralph Deffke napsal(a): >>> NO NO NO >>> >>> OOP is the best ever inventet !!!!! >>> >>> see my comments on this list, I will also come up with an pure oop >>> opensource OMS very soon. >>> >>> I just think a dam big pattern catalog like this one is like an elephant >>> chacing mice. I mean I can think of customers asking for a >>> documentation of >>> course of the page u created for them calling the next day asking >>> wher the >>> hell are the code for the page are documented in the 1000 pages of >>> documentation u had to give them. >>> >>> I can think of two of my largest customers with their intranet >>> application >>> with 23000 members and more then 50000 hits during working hours where I >>> startet sweating while figting for every 1ms. >>> >>> I'm thinking of people with even more hits a day, they even dont >>> start using >>> PHP >>> so I dont know if thats the right way to blow up with includes and >>> thousands of classes. >> >> I deeply and completely agree. > > Yes, certainly optimize on an as-needed basis. But well written PHP code > should certainly scale quite well horizontally. Extremely traffic laden > websites are quite likely to see a bottleneck at the database before a > bottleneck in the code. Hi, You all should understand that on high traffic sites, C or C++ is far more frequently used and called "PHP" because they use a whole lot of custom extensions to speed things up. In addition, memcached speeds up database access so much that the speed of PHP starts to matter. This is why PHP 5.3.0 is somewhere around 30% faster than any previous PHP version when running common applications, because the core developers realized that the base efficiency begins to matter and spent considerable effort improving basic language performance. There are a lot of ways to improve PHP's efficiency, and arguing over whether to use design patterns is not a particularly effective one. Profiling early and often to understand the slowest portions of your code is an effective method. There are many, many talks/videos/etc. that can be found via google.com which discuss these principles, but suffice to say that xdebug, APC, and most importantly siege and apache benchmark are your friends in this endeavor. For Ralph: it might help you to know that facebook.com improved their performance by splitting up things into lots and lots of classes, and using autoload. I don't have specific details because I don't work there, but the programmer who coded this solution was telling me the generalities at php|tek 2 years ago. The pages that saw improvement were ones with a large number of possible execution branches in different requests. autoload simply reduced the number of needed files to the bare minimum from a wide variety of choices. This surprised me, because the prevailing opinion at the time was that autoload always reduces performance. The point to take from this story is that what you think to be true doesn't matter, the only thing is really understanding where your bottlenecks are by profiling aggressively, and even more important, why its slow, so you can fix it. Greg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
