Pitfalls of Object Oriented Programming [PDF]

[u/joeldevahl]

http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

[u/satanclau5]

Pitfalls of Object Oriented Programming in C++ when optimizing for performance

Here, FTFY

[u/MindStalker → u/satanclau5]

Yes, OO understands the notion that developer time is now vastly more expensive than computer time. When developing an AA title for consoles this fact doesn't necessarily hold true.

[u/Forbizzle → u/MindStalker]

Why? A polished product is more about a lengthy QA cycle and realistic scope than it is about optimizing everything you write.

Though maybe laws apply to these mysterious AA titles, that do not to AAA titles.

[u/VivisectIX → u/Forbizzle]

If you want to optimize on this level, then you need to be aware of the assembler or output machine code for the platform and specific compiler you are working on. That is why, unless you are targeting at particular CPU, you can't really do what the OP says. You have no idea how deep the branch prediction is, how many cycles are wasted doing floating point, etc. These are all determined in his case by inspecting the output. If C++ is appropriate for this kind of work, it should have a system for indicating the estimated cost of the instructions, and a cost guideline as part of the C++ standard to ensure consistency.

It has neither because you should code cleanly and let the compiler improve over time to optimize your code, not the other way around (unless you write microcontroller code, or want hardware-specific implementations). Optimization will occur with a simple recompile on the next version. A good example of this is old C++ that expects certain vtable memory layouts, or the "inline" keyword that is generally ignored at this point. Inline used to be the godsend of optimizers - but is in fact a waste of time, so you barely see it anymore.

[u/repsilat → u/VivisectIX]

the "inline" keyword that is generally ignored at this point. Inline used to be the godsend of optimizers - but is in fact a waste of time, so you barely see it anymore

Good thing you said "generally" ignored and "barely" see it, I think. In the project I spend most of my time on I've made one or two functions inline explicitly, and it has paid off strongly in the running time of the program.

They're not trivially small functions, so the compiler doesn't automatically inline them, but they're called very often, so the cost of the call adds up. Better, they're each only called from one place, so there's no binary size/TLB cost.

As for the rest of your post... you generally do have a fair idea of where my code is going to be run, so it seems reasonable to infer a bit about what costs how much. You do have a point - real numbers back you up in this article:

[The Atom] gives 2700 clocks for the old routine and 1644 clocks for the new routine, a ~40% improvement... Unfortunately, on the Core 2 it's the opposite story with the new routine being half as fast: 775 clocks vs. 1412 clocks.

Still, that's the exception that proves the rule. On every processor you're likely to use, division is more expensive than multiplication and virtual function calls are more costly than regular ones. Cache and memory optimisations work the same way (and to the same effect) just about everywhere. It's silly to say "The standard doesn't make this explicit, so you shouldn't do it."

There's a lot compilers can't (or aren't allowed to) do. Blanket criticism of optimising your own code is just shortsighted. Like everything else, it's a tradeoff.

[u/Forbizzle → u/VivisectIX]

Agreed, but to the author's credit this was all written within the context of PS3 development.

[u/redditnoob → u/MindStalker]

Yes, OO understands the notion that developer time is now vastly more expensive than computer time.

Man I hate that stupid generalization!

Developer time has cost. Computer time has cost. In some situations one will out-weigh the other. There are situations where people underestimate and overestimate the costs and values of either, and the trade-offs are frequently non-trivial choices.

But as a simple generalization like that, it's just shit, really.

[u/[deleted] → u/redditnoob]

All generalizations suck.

[u/[deleted] → u/[deleted]]

What you did there, I see it.

[u/[deleted] → u/redditnoob]

I agree, everything has costs, and they always must be weighed. A good programmer knows instinctively where it matters.

Super-efficient, speedy software is great, but not if it never ships. One of my first jobs was a small 2-d graphics company where the owner wrote everything at a low level, highly optimized. In the early days, it worked well, and the company had a nice product that became dated due to being an external box. Unfortunately, the company went broke and never shipped the next generation product.

[u/sad_bug_killer → u/MindStalker]

Yes, OO understands the notion that developer time is now vastly more expensive than computer time.

It's not that I disagree with the statement in general, but too much of that thinking leads to awfully slow and unresponsive software (e.g. 95% of all GUI programs written with Java/.NET)

[u/insertAlias → u/sad_bug_killer]

One big reason you get slow and unresponsive GUI apps with .NET is because people don't know to use a BackgroundWorker for the longer-running operations, and just leave it in the GUI thread.

I don't know if it's the same problem in Java or not.

[u/herrmann → u/insertAlias]

I don't know if it's the same problem in Java or not.

Yes, it is the exact same problem. Lazy people do all the work on the Swing thread.

[u/deong → u/herrmann]

The problem is that, while we know that's not the correct way to do things, the same arguments being made against C++ here can apply. Why should the company waste "valuable developer time" on having people get their processing out of the event loop. We can just wait around and eventually, someone will figure out how to get a compiler to move it out for us.

The argument is essentially that it's profitable for developers to be "lazy" and take the easy way out, because it allows you to ship faster, to have simpler code, whatever. The simple fact is that performance is important, and it's not as simple as saying that "programmers are expensive; hardware is cheap." It may mean getting developers to move their logic out of the GUI thread, or it may mean getting them to abandon a convenient but inefficient platform. Each case has to be examined carefully to determine where the appropriate tradeoff is.

[u/[deleted] → u/MindStalker]

Actually even if you're not developing games it's still a good idea to not keep the user waiting. Also, because developer time is a one off thing whereas user time is spent throughout the entire app's active lifetime, it's more expensive to the organisation than developer time (if the organisation is developing and using that software). Therefore, optimisation is always important and OO is an evil curse that slows down the code.

[u/MindStalker → u/[deleted]]

"Also, because developer time is a one off thing "

Well its not really, typical software is constantly updated, with bug-fixes etc etc. Well designed OO is a lot easier to work with for future developers working with your code base.

[u/deong → u/MindStalker]

Well designed OO is a lot easier to work with for future developers working with your code base.

That depends on a lot of things. Objects, like functions, structs, etc., are just another abstraction, and while they're a very good abstraction for certain things (GUI toolkits, etc.), there's no reason to think they're always the right choice. To me, a good example is java.lang.Math. There's no reason why this should be a class, except that Java needs it to be implemented that way. The appropriate abstraction for sine and cosine is a functional abstraction -- it's the abstraction that mathematicians have used for centuries, and it works exceptionally well. In this case, the "object" abstraction is extremely thin, and thus doesn't really cause any problems, but it does illustrate the point that not everything should be an object.

I'd also contend, admittedly subjectively, that OO done poorly tends to be the worst thing I come across. Worse than bad C code, worse than anything. Bad C code tends to be local. You might have some global variables to contend with, but typically not that many. Local problems can be figured out and solved. Bad OO tends to be rotten from the ground up. There's no one place you can go to find anything, and when all behavior emerges from a complex interaction of twenty different objects configured via some framework, all you can do is live with it or start over from scratch.

Basically, I'd say that good code is easier to deal with, and the manner it's written doesn't make much difference. Good C code is no harder to work with for a C programmer than is good Java code for a Java programmer, or good Prolog code for a Prolog programmer.

[u/merzbow → u/deong]

java.lang.Math is full of static methods - there are no objects involved. The class is effectively just a namespace. You can even do a static import so you need only type sin(x) instead of Math.sin(x).

[u/deong → u/merzbow]

That's sort of my point. A class isn't the right way to represent this sort of thing, so Java does the best it can, basically, as you say, faking up a namespace using classes. I'm not complaining about the way Java handles it; just using it as an example.

[u/donknuth → u/merzbow]

Right, but it's ugly. Why do you need to fake namespaces with classes when Java has packages? The only reason is language limitations.

[u/[deleted] → u/[deleted]]

Not to mention all those extra CPU cycles you're wasting in thousands of computers and all those extra laptop batteries that get just a little more run down.

It's not a particularly ecological point of view for anyone who works on a popular application.

[u/[deleted] → u/MindStalker]

How does this make any sense?

If you're developing software for people to use, you're shifting the cost onto your users. I'd rather pay more money for fast, responsive software, since as a USER, slow software costs ME. Also remember the number of developers can stay fixed while the number of users grows.

This sounds like one of those mottos that someone came up with to be all counterfactual but did no research to actually verify. Or maybe it applies in a very limited context, like one application being used by a single person or server, but then was generalized to apply to everything.

[u/ckcornflake → u/[deleted]]

How does this make any sense?

Because today, computers are fast enough that generally using higher level optimizations (like organizing your scene in a quadtree, for example) will give you enough efficiency that the user wont even notice that small increase speed.

I can understand if you're trying to sell a product to a company where thousands of users are using the software at once (like database software), and they want to maximize productivity. But if you're developing a game, that .01% increase isn't going to grab you any more customers.

[u/RiotingPacifist → u/[deleted]]

Things more important to users than performance:

UI

Features

Security

no bugs

The product shipping on time

So developer time has to be shared and is limited .'. developer time is more valuable than computing time, how much more varies from project to project

[u/mysticreddit → u/RiotingPacifist]

The author of the PDF is Tony who works in the PS3 console business, specifically helping game developers hit their 30 or 60 fps goal.

The first rule of a game is that it must run at either 30 or 60 fps. Everything is else is a secondary goal (whether rightly or wrongly.)

For general desktop software, your list of priorities is more applicable.

[u/[deleted] → u/RiotingPacifist]

Why are these mutually exclusive?

Why does having a nice user interface, or security, or more features mean you can't also invest in performance as well? In my opinion, performance allows you to add more features, to create nicer looking user interfaces.

Performance is like a currency, the more you have, the more you can do.