Beginner OOP questions

Question

Hi, I just want to ask two quick questions about OOP.

First, is the code actually produced by OOP language compiler any different from procedural language compiler? I mean, is OOP just about how you write the code, or is the actual compiled code different from procedural? More accurate, procedural languages like C basically produce code like it would be written in ASM. But is OOP code any different?

And second, if OOP code uses different approach in its machine code form, is it slower or faster than procedural? Thanks.

Answer 1

All languages produce the same code, like ASM (machine code), except languages that produces bytecode (ex: Java) or interpreted languages (ex: Python, PHP)

Answer 2

First, no. For languages that are compiled to native machine code, this is certainly true. After all, assembly and machine code have no notion of objects.

For languages which run in a virtual machine like Java or C# this is partially true. Here, the VM may support some object-specific features.

It is possible to write OOP in non-object-oriented languages, and the other way around. OOP is mainly useful for the programmer, and the restrictions it imposes (that you can not access private methods from another class, for example) are checked by the compiler but not passed on in the output.

Second, there is no performance difference for OOP or procedural. It is just that the code and the data are located in different places in the code.

Answer 3

I'm not exactly sure about the actual performance difference between procedural code and object-oriented code, although I firmly believe it shouldn't make that big of a difference at the end of the day.

However, any programmer that understands the different OO principles has a much easier time reading and understanding OO code as it allows for easy abstraction of different complexities.

Basically, my point is the following: the gains from having code that is easier to read, re-use and maintain would easily justify a small performance loss (if any), most of the time.

Answer 4

That depends a lot on the actual algorithm you're trying to implement, and on the compiler (those have gotten very smart in the past years). The compiled code definitely won't be byte-for-byte identical, and it may be even completely different (again, depends on the algorithm you're implementing). In reality, it doesn't matter.

The difference in speed of the program will be negligible in most cases - unless you're doing something grossly inefficient in one form or the other (and this will be most likely related to your business logic and the algorithms you'll use to implement it, not to programming paradigm), this won't be a concern.

The other, often neglected but crucial, speed difference lies in maintainability: computer time is, in most cases, cheap; programmer time is expensive. (That's not to say "write bloatware", but rather "don't waste a week figuring out how it works when somebody else needs to update the logic, three years from now")

Answer 5

All code eventually comes down to machine code. There are only certain ways to represent data in memory. I would imagine that the ASM code depends entirely on the compiler and if you're performing optimization. For byte-code-compiled languages, the source is compiled to bytecode and then run through an interpreter. There may even be a JIT (Just-In-Time) compiler that compiles that bytecode into native machine-code.

You have to realize that OOP is an abstraction or paradigm that makes it easy for the programmer to solve problems. As such, it doesn't have any real bearing on efficiency. Assembly code usually has a section that deals with describing or allocating data, and another section for program code. So all compiled code ends up in this state.

If you are actually concerned about efficiency of code generated, you should be looking at the compilers themselves and reading about the kind of code they generate. Most modern compilers perform all sorts of optimizations (and you can even tell them what level of optimization you want). Of course, this mostly comes into play when you are programming in an embedded environment.

The paradigm mostly doesn't have a bearing on efficiency, but of course, some languages are more efficient in certain environments. C, for example, performs very well in an embedded environment. The ultimate aim is to choose the right tool for the job. For example, I'm sure you could use brainf*ck to write embedded code, but brainf*ck is not a very convenient language. You might be better off with C. If you want to do embedded programming, but want to use the OOP paradigm, you can try doing embedded C++ or even embedded Java.

Answer 6

Fundamentally, all computer programs are procedural, as they execute as a series of steps on the CPU. The machine code generated by a compiler for a procedural language and one for an object-oriented language can be very similar. OOP is just an alternative abstraction -- a tool to make code more maintainable and easy to write.

OOP is not generally faster/slower than procedural. This really doesn't matter that much anyway, considering that the rgeatest speed gains are to be had by choosing efficient algorithms rather than optimizing individual instructions. And benchmarks are often too debatable to be of value.

Answer 7

There's always some compromise to make between efficiency and maintainability.

WHile procedural may execute faster (although not necessarily significantly, and this is all relative...), you cannot really make scalable project with procedural code. OOP is not meant to optimize performance in application, but help developers solve real world problems with a programming language. As applications require more and more complex user interfaces, business models and tend to have longer life cycles, OOP is a solution that fit nicely with just about every today's projects.

In the end, OOP or not, native compilers will generate ASM code or VM will generate bytecodes (for JIT compilers). It is important not to mix OOP paradigm with compiled code; the computer doesn't care how the code is organized and will execute it just the same. Of course, a procedural code will be different than a OOP one once compiled. However, I would not go as far as saying that OOP is just "about how you write the code", simply because the performance of a procedural application will always go faster downward as the project expands than a OOP one.

Answer 8

Actually, normally Objected Oriented code will result in something a (very) little slower. The reason for this is that Objects and classes have overheads - even though the actual code becomes procedural, there's still "stuff" going on in the background. A nice comparison of C and C++ can be found here:

http://unthought.net/c++/c_vs_c++.html (look about half way down the page or do a text-search for the term "Quite a difference! At 567%" if you want to go right to the surprising bit).

It's a little old but still very valid. In most cases though, the speed boost is not worth the extra time it takes to write the code - this is a really extreme example, and remember C is a very low-level language; in fact I don't know off the top of my head of any other language that will beat C++ so comprehensively in a straight speed-test.

Also note that poorly written procedural code will almost always be slower than well-written OO code (I think someone has mentioned this already).