PHP Optimization
Moderator: General Moderators
Yes.. if you install Linux and reboot.MarK (CZ) wrote:Can I get "top" running on Win machine?
Seriously, this is just one of the limitations of Windows for web development. With Linux you can muck about with apache, build from source (at home I never could get Xdebug to work in windows) and generally explore the most common environment under which server apps are run.
PS: Xdebug can also give information on memory usage: http://www.xdebug.org/docs-functions.ph ... mory_usage.
Haha ... you're offended by the term Mr Spaghetti? Are you kidding me?Buddha443556 wrote:First I really don't think name calling, should be part of this discussion. Especailly when the one doing the name calling is a moderator. Stooping to such level doesn't help your arguement.McGruff wrote:Let's say we have two almost identical apps: one written by Mr Spaghetti and one carefully refactored into lean & mean classes by Mr Oop. Both work, and Mr Spaghetti constantly annoys Mr Oop (who has better things to do) with the latest sightings on the edge of reality from his Hubble telescope.
One day the client wants to make a big change to the site. The update is carried out, both sites are still using the "same" underlying code, and both have slowed right down. Mr Oop starts examining the system to find the bottleneck. Within an afternoon, with his nice modular design, he has identified the problem and swapped out the problem code. Mr Spaghetti spends all day just trying to figure out his own script - he's long forgotten how it works and the mess on the page doesn't explain itself. He spends all week looking for bottlenecks: because his script is so tangled, it's a huge effort to compare alternative ideas.
How can I possibly take anything you say seriously after that comment?
When maintatining proceedural code that is almost always horrid to deal with due to its lack of modularity, it's 99% understanding what the hell the program is doing and the dozens of pages that one change affects, and 1% improvement/functionalityBuddha443556 wrote:I always thought programming was 99% thought and 1% effort. Maybe I'm doing it wrong?McGruff wrote:At least 2/3 of the effort of programming goes into writing code that is easy to assimilate and easy to work with. The other side of that - making a computer "do stuff" - is a relatively trivial task.
What? A well designed app is modular, hence any changes or optimisations (if properly designed) are localised in one place. That's the entire point of design and OOP. If it is well designed, it is NOT as challenging to improve than if it is badly designed - which is harder to improve since the changes are all over the place.Roja wrote:I disagree with that statement completely - the LESS well designed the app, the MORE benefit you can get from optimizations. If its well designed, its going to be VERY challenging to improve that.McGruff wrote: It's just an attempt to explain an important point: without a well-designed app, it's going to be tough to do any optimising at all.
Ummm ... flexibility is where the system is built from small pieces that do just one thing. That way, if anything needs to be changed, the change can be found and modifiied in a less number of places instead of many places. If a method does many things, then a change will propogate through all the layers instead of just the ones aboveRoja wrote:I disagree. Flexibility means "Responsive to change; adaptable" - the opposite of doing just one thing, the ability to do many things as needed.McGruff wrote: Flexibility arises from paring down classes and fns until they do just one thing. Reduced dependency = more flexibility.
Hehe ... touche =)markl999 wrote:If you care that much about speed, don't use PHP.
Ooops..did i just say that out loud![]()
And while I kinda agree - if you know you're stuff well enough to optimise, then the difference in language will be only an issue in the extreme minority of cases that might require C++ like real time apps.
Why is that? Though I might not always agree with McGruff on certain things, he is very trust worthy, and very intelligent.Buddha443556 wrote:I'm having trouble with that.McGruff wrote:Trust me, it is.
So it's usually not a good idea to sit there and say it's a massive improvement.Buddha443556 wrote:True, and I said they were very unscientific.McGruff wrote:Those test results aren't entirely reliable with just six iterations.
You're wrong. Optimization, by it's very nature, can't be done until AFTER the program is complete. This is not to say you don't program in an efficient manner from the beginning, but to say you cannot optimize any code until after it's written. It's been proven time and time again that pre-optimization, which is what you are advocating, does more harm than good.Buddha443556 wrote:Here we disagree greatly. You, correct me if I'm wrong, you think of optimization as something you do after all the coding is done. Where as I see as being part of the entire design and development process. Not an after thought.McGruff wrote:Even if you had achieved a speed increase of less than 2 hundredths of a second what impact will that have on your site? How much time did you spend to figure that out, and how much time would you subsequently spend to update all the scripts in the site according to your findings?
There is a lot of bantering back and forth here, and while I have my opinions, I am going to shoot for some straight facts that I have learned over my years or programming.
Please also note that I am not FOR any side here. As McGruff will attest to, him and I have, on many occasions, agreed to disagree.
That being said, here are some things to keep in mind:
1. Premature optimization is worse than no optimization. You can't optimize what you can't benchmark. For those of you advocating that optimization is apart of the development and design stages, I can only wonder how you determine if your optimization actually works without a benchmark.
2. Everyone is off base with regards to where programmers spend most of their time. If you believe you spend most of your programming time designing, developing, code, optimization, etc, than you have obviously forgotten what we programmers really spend most of our time on. Maintenance. Code maintenance is really where we spend most of our time. This means that code that is difficult to maintain is going to be problematic, and more difficult to optimize.
3. Someone mentioned that functionality of objects and function has a direct relation with flexibility. That's not true. A function should do one thing, and do it well. An object should do one set of things with data, and it should do it well. A function or object that does too much is a bad thing, and in fact, makes the program less flexible. Anyone that disagrees can come visit me and I will show you some of my code. =)
4. Optimizing your code has less to do with the syntax and more to do with formulas that you are using. For example, I wouldn't say using , instead of . when using echo an optimization. It's simple correctly using a language feature. It's the difference between good programming practices and poor ones. Optimizing is not a syntax change, it's a formulaic change.
5. Optimization is not always good. Just because the code runs faster doesn't mean it's better. It's easier to optimize code that is properly structured and designed than to optimize code that is poorly designed. Why is this? Because with the poorly designed code, the fact that the code is poorly designed may (will) hamper your efforts to optimize. Sure, there is the argument that by optimizing poorly designed code will result in a greater performance increase, but the amount of work needed to see any optimization will require more work.
6. The degree of the optimization is offset by the amount of work required to implement an optimization. If the amount of work is too great, the optimization is not efficient. For example, in this case, the original poster (if I read everything correctly), switched from one method of including templates to another, for a small increase of 13%. In a small script, it might work fine, but on a larger system, such a change might require lots of work, when in reality, the problem can be solved in other ways.
(please note that a percentage is not always an accurate measure of optimization success, for example, something that takes 0.00000002 seconds to run, and by making a change, now it runs 0.00000003 means you have slowed the system down by 50%. Sounds bad at a percentage level, but in reality, means nothing).
7. PHP is rarely the bottleneck. The formulas you are using, the database, the bandwidth, the CPU or the system the program is running on, your distance from the server: these are all issues that can cause problems. These, in my experience, are usually the first culprits for a slow running system. PHP itself is rarely the problem (unless you are misusing PHP, for example, creating a few thousand objects).
Finally, I have one more thing to add that is slight off-topic:
The Mr. Spaghetti v.s. Mr. OOP manuscript was funny. It's not making fun of anyone, nor should it be taken as an insult. Frankly, IMO, taking it like that means you might want to take a breather, and just think for a moment what the intent is. I've written spaghetti code myself, and frankly, the statements were very true. If you are going to take offense to that sort of stuff, seriously, you might have anger/stress issues.
Again, my goal here is not to cause an additional problems, but to try and keep things on topic. I just read this thread and it felt like people were 1) itching for a flamefest, and 2) people weren't really reading what the other person was saying. Frankly, a lot of smart things are being said that are getting lost in the quips and the snipes.
Finally, yet again, there is one thing I will address directly: Everyone here is a human, and from what I can tell, no one is a saint. Holding moderators to some glorified position above other people is, well, wrong. We are moderators, not saints. To think any differently is to set youself up for disappointment.
Anyways, hopefully this thread can stay on topic, and remain a good wholesome discussion on the finer points of optimization.
Please also note that I am not FOR any side here. As McGruff will attest to, him and I have, on many occasions, agreed to disagree.
That being said, here are some things to keep in mind:
1. Premature optimization is worse than no optimization. You can't optimize what you can't benchmark. For those of you advocating that optimization is apart of the development and design stages, I can only wonder how you determine if your optimization actually works without a benchmark.
2. Everyone is off base with regards to where programmers spend most of their time. If you believe you spend most of your programming time designing, developing, code, optimization, etc, than you have obviously forgotten what we programmers really spend most of our time on. Maintenance. Code maintenance is really where we spend most of our time. This means that code that is difficult to maintain is going to be problematic, and more difficult to optimize.
3. Someone mentioned that functionality of objects and function has a direct relation with flexibility. That's not true. A function should do one thing, and do it well. An object should do one set of things with data, and it should do it well. A function or object that does too much is a bad thing, and in fact, makes the program less flexible. Anyone that disagrees can come visit me and I will show you some of my code. =)
4. Optimizing your code has less to do with the syntax and more to do with formulas that you are using. For example, I wouldn't say using , instead of . when using echo an optimization. It's simple correctly using a language feature. It's the difference between good programming practices and poor ones. Optimizing is not a syntax change, it's a formulaic change.
5. Optimization is not always good. Just because the code runs faster doesn't mean it's better. It's easier to optimize code that is properly structured and designed than to optimize code that is poorly designed. Why is this? Because with the poorly designed code, the fact that the code is poorly designed may (will) hamper your efforts to optimize. Sure, there is the argument that by optimizing poorly designed code will result in a greater performance increase, but the amount of work needed to see any optimization will require more work.
6. The degree of the optimization is offset by the amount of work required to implement an optimization. If the amount of work is too great, the optimization is not efficient. For example, in this case, the original poster (if I read everything correctly), switched from one method of including templates to another, for a small increase of 13%. In a small script, it might work fine, but on a larger system, such a change might require lots of work, when in reality, the problem can be solved in other ways.
(please note that a percentage is not always an accurate measure of optimization success, for example, something that takes 0.00000002 seconds to run, and by making a change, now it runs 0.00000003 means you have slowed the system down by 50%. Sounds bad at a percentage level, but in reality, means nothing).
7. PHP is rarely the bottleneck. The formulas you are using, the database, the bandwidth, the CPU or the system the program is running on, your distance from the server: these are all issues that can cause problems. These, in my experience, are usually the first culprits for a slow running system. PHP itself is rarely the problem (unless you are misusing PHP, for example, creating a few thousand objects).
Finally, I have one more thing to add that is slight off-topic:
The Mr. Spaghetti v.s. Mr. OOP manuscript was funny. It's not making fun of anyone, nor should it be taken as an insult. Frankly, IMO, taking it like that means you might want to take a breather, and just think for a moment what the intent is. I've written spaghetti code myself, and frankly, the statements were very true. If you are going to take offense to that sort of stuff, seriously, you might have anger/stress issues.
Again, my goal here is not to cause an additional problems, but to try and keep things on topic. I just read this thread and it felt like people were 1) itching for a flamefest, and 2) people weren't really reading what the other person was saying. Frankly, a lot of smart things are being said that are getting lost in the quips and the snipes.
Finally, yet again, there is one thing I will address directly: Everyone here is a human, and from what I can tell, no one is a saint. Holding moderators to some glorified position above other people is, well, wrong. We are moderators, not saints. To think any differently is to set youself up for disappointment.
Anyways, hopefully this thread can stay on topic, and remain a good wholesome discussion on the finer points of optimization.