On Feb 9, 2010, at 4:10 AM, Josh Dersch wrote:
That's certainly an issue. I wonder how many
applications are
slower and more overweight due to their being crafted with OOP than
they would be if they were coded using more traditional methods.
"More traditional methods"? Just "the way processors execute
code" would be a good start. Processors aren't object-oriented in
nature. This is one of the reasons why we have computers with
multi-GHz processors that barely get out of their own way. The
constructs commonly used in OO programming don't come anywhere close
to mapping to hardware efficiently.
What "commonly used" constructs are these that are so horribly
inefficient that they would make a multi-GHz processor stumble? (And
in what language(s)?)
OBJECTS!
Our processors have registers, ALUs, and memory locations...not
objects. (iAPX432 notwithstanding) Constructs that don't map to that
paradigm are going to be inefficient, to a degree that corresponds to
how badly they match the paradigm. And objects don't map to it at all.
That's not answering my question. What part of implementing OBJECTS!
are modern compilers for OO-language-du-jour incapable of translating
efficiently to native machine code? And why? And what exactly is the
performance hit in the cases you're thinking of?
How, precisely, do objects NOT map to registers or memory locations in
modern OO languages? Where does the inefficiency come in? How much
faster than a Sparc IPX running FVWM would my machine be if my existing
software had been written in C instead of
horribly-inefficient-language? Details, please.
Josh