will changing all code to object oriented make mem

问题:

There is a project written in PHP that is just simply all procedural ... step by step calling DB functions, processing, and printing out the output. And then it is changed to totally object oriented -- there is a singleton for the App object, and various functions are invoked through the App object.

Someone claims that the memory usage or footprint on the server will be less. Would that be the case? I thought procedural often just uses the bare minimal, while Object oriented programming with various design patterns usually instantiates more things than needed, or simply have objects around while procedural usually just have the bare minimal.

So will changing all code to object oriented actually make the memory usage on the server smaller?

回答1:

It will probably make it more, but there's really no way to tell. If your code actually improves by doing it in an OOP way, then it may be less. There is no direct correlation between memory used and the presence of object oriented ness. Maybe in general, object oriented takes more memory, but only if both sets of code are written equally well, and that's almost never the case.

Is there a reason this application is being upgraded to be objected oriented? You know it's not one or the other, you can mix and match pieces... OOP is not a silver bullet.

回答2:

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?

Basically, what I'm hearing from all my OOP fans is that... You will use more resources, it will be just as fast as well written procedural function calls, but it will be better for large projects and multi-developer environment. A balance needs to be found.

More devs (sloppy devs) and larger site

Con: More RAM used for your app.

Pro: Easier to maintain the code among many across the whole app.

One dev with a simple site

Con: If your site grows, or starts to include many developers, development might be a bit slower if your procedural code sucks.

Pro: Low RAM, slightly faster speed. If your code is written properly (and only good developers can do this - haha), your code will be just as easy to maintain.

In the RAM wars, Procedural wins. In the maintainability wars, good code wins. ;)

OOP fans say that OOP is cleaner. I've seen some really messy OOP code, and then I've seen some REALLY CLEAN procedural code, written by developers who could write great code in any language or style. Code that made it a pleasure to work with. The bottom line is that if you have sloppy developers, it won't matter which style you use, you're gonna have sloppy code.

Because of my very own personal benchmarks, I opt out of memory hog OOP, mainly because I do write really clean procedural, and I'm usually the only dev on any of my projects.

Cheers!

回答3:

Your question sounds like this to me: We have a unmaintainable code-base, will rewriting it in Java make it faster?

First, you need to identify the problem: is your code unreadable and/or difficult to maintain or is your program's runtime footprint too big? These are two completely different problems.

If you have a code base which is difficult to maintain (it sounds like you do), you'll not solve that by rewriting the code using another paradigm. Why is the code unreadable? Are the developers writing unreadable code, then rewriting it in Java or C# will just give you object oriented unreadable code. In that case you need to improve the skills of your developers (hire better ones, reeducate the existing ones, etc.).

If you have a problem with memory footprint, then you should approach that as any other performance problem. First measure, then do some optimization (rewrite some piece of code to make it more memory efficient), and then measure again. Measuring before and after is important to make sure that you're not making things worse. And believe me, even very good coders do that mistake.

回答4:

The answer is both yes and no.

By switching to a more object oriented architecture you could reduce the memory footprint, but if and only if the code is more efficient.

Straight PHP without any function calls or object calls is rather quick. As soon as you start making function calls or object calls things start to go much slower.

From A Python Vs Ruby Vs. Python Benchmark an OO strategy for doing an incremental loop took 3.7079 seconds, function oriented took 4.3501 seconds, and using neither took 0.6164 seconds. Doing a simple "Hello World" app with OO vs. Procedural Vs. Neither yeilded a 4.1248 seconds vs. 3.7656 vs 0.9309 seconds.

So depending on what your code is doing and how it's doing it, objects could be both faster or slower, more memory intensive or less memory intensive, or neither.

回答5:

And then it is changed to totally object oriented -- there is a singleton for the App object, and various functions are invoked through the App object.

That actually sounds like pretty much the opposite of "totally object oriented". This indicates a level of understanding of what "object oriented" means that will most likely NOT result in a reduced memory footprint.

In general, the design will have a far greater influence on the memory footprint than the programming paradigm, though it is probably true that on average, object oriented apps tend to have a bigger footprint.

回答6:

Memory usage isn't the advantage of OO. The advantage of OO is that the code will become more maintainable. If you're not having performance issues there's no need to go looking for ways to be more efficient.

回答7:

In addition to the other comments, I would like to say that OO helps reduce redundancy... which might make your code more efficient, and reduce memory footprint. Of course, OO has more overhead, but should work out more efficient in larger projects.