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.


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 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 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.


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to