On Dec 31, 2007 3:47 PM, Michael McGlothlin <michaelm@xxxxxxxxxxx> wrote: > Nathan Nobbe wrote: > > On Dec 31, 2007 3:37 PM, Michael McGlothlin <michaelm@xxxxxxxxxxx > > <mailto:michaelm@xxxxxxxxxxx>> wrote: > > > > Richard Lynch wrote: > > > On Sat, December 22, 2007 12:25 pm, Sascha Braun wrote: > > > > > >> Hi Fellows, > > >> > > >> I figured out, that PHP5 runs faster when I am not inherit > > classes, > > >> I hope I use the right word. > > >> > > >> I mean the class sub_class extends main_class notation. > > >> > > >> As well I figured out, that I in most cases should references in > > >> foreach loops. like > > >> > > >> foreach($array as $key => &$value) { > > >> > > >> } > > >> > > >> Lots of memory is saved by that. > > >> > > >> Now I would like to know, what other speed improvements might be > > >> possible. What about autoload of classes, will it improve speed > > >> when I throw the code out? > > >> > > >> Are there other things I should take care of. > > >> > > >> I would like to know as much as possible. Please go deep into > > your- > > >> self and tell me every little thing on how you improved your > > applica- > > >> tions for speed and memory optimisation, to make this thread > > the best > > >> compendium on performance and memory optimisation. > > >> > > >> Thank you very much, fellows and a merry merry christmas! > > >> > > > > > > I never optimize code unless there's a problem with its > > performance... > > > > > > Why one would tweak code endlessly to maximize performance when > > that's > > > not needed is beyond me... > > > > > > But maybe I'm just a Luddite. > > > > > > > > Hardware is cheaper than man hours. Just throw more CPU power at the > > problem. > > > > > > thats only true until poorly designed software cant be spread across > > machines > > due to a monolithic nature. > > get an opcode cache and index the database; that will probly absolve > > any noticeable > > speed problems. > > > > -nathan > Well obviously you can always write horrible code but if you write code > that is easy to maintain it's usually not that kind of code. thats pretty subjective; ive worked w/ plenty of 'easy to maintain' code that could only have hardware thrown at it by a load balancer. which i consider a real mess. even then the design of the load balancer will have to maintain request forwarding to particular hosts unless the code already supports or is given support for session storage in a common location all the webservers can address. i personally am not a fan of the 'just throw hardware at it' adage, if it can be called that. i was recently at the d.c. php conference and heard a talk from a gentleman on behalf of yahoo. he says they are *very* picky about getting new hardware; yahoo wants clear rationale for the addition of any new hardware into the system. in short; they advocate writing solid code because it saves them money in the long run. what i see happening when people throw hardware at their problem is that in early stages it works great. then further down the road the software is unable to be easily spread to multiple systems and then guess what; you end up spending man hours to do something that could have been done in the first place. another issue is randomly added machines can be hard to maintain because their roles are not clearly defined. what im saying is adding hardware to a system is natural and relevant, but ensure it is a good decision by evaluating alternatives before arbitrarily 'throwing hardware at the problem'. -nathan
