In interpreted programming languages, such as PHP and JavaScript, what are the repercussions of going with an Object Oriented approach over a Procedural approach?
Specifically what I am looking for is a checklist of things to consider when creating a web application and choosing between Procedural and Object Oriented approaches, to optimize not only for speed, but maintainability as well. Cited research and test cases would be helpful as well if you know of any articles exploring this further.
Bottom line: how big (if any) is the performance hit really, when going with OO vs. Procedural in an interpreted language?
Maybe I'm crazy but worrying about speed in cases like this using an interpretive language is like trying to figure out what color to paint the shed. Let's not even get into the idea that this kind of optimization is entirely pre-mature.
You hit the nail on the head when you said 'maintainability'. I'd choose the approach that is the most productive and most maintainable. If you need speed later, it ain't gonna come from switching between procedural versus object oriented coding paradigms inside an interpreted language.
Unfortunately, I've done my tests too. I did test speed, and it's about the same, but when testing for memory usage getting memory_get_usage() in PHP, I saw an overwhelmingly larger number on the OOP side.
116,576 bytes for OOP to 18,856 bytes for procedural. I know "Hardware is cheap", but come on! 1,000% increase in usage? Sorry, that's not optimal. And having so many users hitting your website at once, I'm sure your RAM would just burn, or run out. Am I wrong?
Bottom line: no, because the overhead of interpretation overwhelms the overhead of method dispatching.
In my experience, a site under heavy load will be bogged down and become unresponsive much more easily with OOP code than procedural. The reason is easy to understand.
OOP requires a lot more memory allocations (MALLOC) and a lot more operations to run in memory than procedural code. It requires a lot more CPU time to perform its tasks. It is essentially 'overhead', wrapped around procedural code, adding to the CPU burden to execute it, especially when performing database operations.
Many programmers like the convenience of OOP, creating little black boxes hidden behind simple interfaces. However, I have been paid well to revive sites that were taking forever to respond under heavy user load. Stripping out the OOP and replacing it with simple procedural functions made a huge difference.
If you don't expect your site to be very busy, by all means use OOP. If you are building a high-traffic system, you'll want to strip every CPU cycle from the processing and every byte from the output that you can.
If you are using an interpreted language, the difference is irrelevant. You should not be using an interpreted language if performance is an issue. Both will perform about the same.
Your performance will be characterized by the implementation, not the language. You could use the slowest language and it could scale to be the biggest site in the world as long as you design it to scale.
Just remember the first rule of optimiztion.
Don't.
:)
I've actually done a small test like this in python on a website I maintain and found that they are almost equivalent in speed, with the procedural approach winning by something like ten-thousandths of a second, but that the OO code was so significantly cleaner I didn't continue the exercise any longer than one iteration.
So really, it doesn't matter (in my experience anyway).
来源：https://stackoverflow.com/questions/3057/speed-comparisons-procedural-vs-oo-in-interpreted-languages