will changing all code to object oriented make mem

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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!

Answer 4

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.

Answer 5

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.

Answer 6

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.