Pit falls to OOP

[glenn]

I am hearing alot about how slow OOP is.
Is there ways to increase its speed? eg better programming,
techniques? I know that one cant compete against
well-writen assembly, but I am sure there there are
pit-falls to avoid with OOP.

Any suggestions? eg like avoid doing alot of sub calls?

[Jay B. Harlow [MVP - Outlook]]

Glenn,

I am hearing alot about how slow OOP is. Really, where you have heard that?

Are you talking coding, execution or maintenance? As I find OOP faster in
all three cases. Of course when working with people who "just don't get it"
OOP coding tends to be slower. However that is not a problem with OOP!

For example: simply OOP techniques such as replacing conditionals (If ElseIf
or Select Case) with Polymorphism may actually speed up your program...
Is there ways to increase its speed? eg better programming,
techniques? Better programming techniques apply whether you do OOP or not.

As I'm sure you are aware well written OOP will perform better then poorly
written OOP, just as well written procedural will perform better then poorly
written procedural. Or well written assembly better then poorly written
assembly.
techniques? I know that one cant compete against
well-writen assembly, but I am sure there there are
pit-falls to avoid with OOP. I don't know being able to quickly write robust programs that are easily
maintained using OOP, while it takes significantly longer to write a
well-written assembly program, seems to be a pit-fall of assembly. Having
maintained a number of assembly programs, I know they are not easy to
maintain.
Any suggestions? eg like avoid doing alot of sub calls? Most of my OOP tends to be smaller classes with smaller sub routines, so it
actually increases the number of sub calls. I have not seen any performance
problems.
The following articles provide information on writing .NET code that
performs well. (OOP or not).

http://msdn.microsoft.com/architectu...l/scalenet.asp

http://msdn.microsoft.com/library/de...anagedcode.asp

http://msdn.microsoft.com/library/de...anagedapps.asp

http://msdn.microsoft.com/library/de...vbnstrcatn.asp

http://msdn.microsoft.com/library/de...tchperfopt.asp

http://msdn.microsoft.com/library/de...tperftechs.asp

Hope this helps
Jay

"glenn" <an*******@discussions.microsoft.com> wrote in message
news:19****************************@phx.gbl...
I am hearing alot about how slow OOP is.
Is there ways to increase its speed? eg better programming,
techniques? I know that one cant compete against
well-writen assembly, but I am sure there there are
pit-falls to avoid with OOP.

Any suggestions? eg like avoid doing alot of sub calls?

[Herfried K. Wagner [MVP]]

* "glenn" <an*******@discussions.microsoft.com> scripsit:

I am hearing alot about how slow OOP is.
OOP is about structuring your sourceocode and make it more readable.
It's not about saving bytes in memory or doing low-level optimization in
assembler code.

So, my suggestion is: Don't care about speed to much if it would
require your code to be hard to understand.
Is there ways to increase its speed? eg better programming,
techniques? I know that one cant compete against
well-writen assembly, but I am sure there there are
pit-falls to avoid with OOP.
Sure, there are some tips and tricks depending on the situation, but I
don't know a general overview over these tricks ;-).
Any suggestions? eg like avoid doing alot of sub calls?

That's hard to say, because the JITter may inline procedure calls to
make execution faster. With .NET, you have few control about to what
MSIL your code gets compiled, and how it looks like when the JITter
converts it to native code.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
<URL:http://dotnet.mvps.org/dotnet/faqs/>

[Jay B. Harlow [MVP - Outlook]]

Glenn,
In addition to Herfried's comments, I should add to my comments:

I find it better to write "correct" programs then to worry about
performance. By "correct" I mean OO and use the correct tool for the correct
job (for example: when to use ChrW and when to use Convert.ToChar). Remember
that most programs follow the 80/20 rule (link below) that is 80% of the
execution time of your program is spent in 20% of your code. I will optimize
the 20% once that 20% has been identified & proven to be a performance
problem via profiling (see CLR Profiler in my other message).
For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware...timization.pdf

For a list of Martin's articles see:

http://martinfowler.com/articles.html

Hope this helps
Jay

"glenn" <an*******@discussions.microsoft.com> wrote in message
news:19****************************@phx.gbl...

I am hearing alot about how slow OOP is.
Is there ways to increase its speed? eg better programming,
techniques? I know that one cant compete against
well-writen assembly, but I am sure there there are
pit-falls to avoid with OOP.

Any suggestions? eg like avoid doing alot of sub calls?

[bharathi]

Infact, it is much better to have a OOPs based application in a
production environment.

All our production apps are written and rewritten in OOPs based
structure, resulting in easier management of maintenance, upgrading,
and modifying.

Regards
Bharati
http://www.vkinfotek.com

[Cor Ligthert]

Glenn,

Yes, it can slow down. As every program is, that is not good written.

One of the extra that the processor has to do is getting all the references
you have made to connect all what is needed.

You probably have never noticed that is in any program. OOOP gives you the
change to do it in a structured way.

When you are writing programs with a dotNet language, (does not matter which
one) you cannot around OOP.

However when you would use this technique on a Commandore 64 in that way it
used on a modern computer, it really would in my opinion slow your program
down.

The same fact as that riding a horse uses less fuel than riding a car.
However, you should have seen the dirt in the streets in the days that it
was common.

Just my thought,

Cor

[Jay B. Harlow [MVP - Outlook]]

bharathi,
I Agree, as that is what I attempted to say in my first message...

Jay

"bharathi" <pe********@yahoo.com> wrote in message
news:cc**************************@posting.google.c om...

Infact, it is much better to have a OOPs based application in a
production environment.

All our production apps are written and rewritten in OOPs based
structure, resulting in easier management of maintenance, upgrading,
and modifying.

Regards
Bharati
http://www.vkinfotek.com

[Chris Dunaway]

On Thu, 22 Jul 2004 08:27:33 +0200, Cor Ligthert wrote:

However when you would use this technique on a Commandore 64 in that way it
used on a modern computer, it really would in my opinion slow your program
down.

The Commodore 64 was a great little computer. Mine lasted a very long time
and it could take a beating and would still work. The BASIC used was far
from what we use now, but it was still very easy to write a program
(although not OOP). I also remember entering programs from magazines by
typing in the data one byte at a time. Very tedious, but rewarding when
the final result ran.

There is an emulator for the C64 available.

Brings back memories.

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.