OO vs Performance

Hi guys, maintainable vs. performance are usually inversely related, something gota give.

Does using Interfaces, Abstract Classes and so on cause a performance delay? theorotically they are syntatics they get compiled to MSIL, does MSIL segregate objects as such as well?

 

Hi.

In terms of MSIL, there is already a performance hit just doing an intermediate language.

To answer your question, yes they do cause a delay. Multiple inheritance, and a deep inheritance tree hits performance due to the virtual tables (in the words of C++). Similarly with interfaces and everything OOP.

MSIL(think OOP in assembly) is somewhat lowlevel already with regards to assembly, and it is meant to be close to assembly syntax as possible to reduce the performance hit to native code. Ultimately it still applies the same techniques as assembly on how it implements OOP.

Double Whammy.

The situation isn't that bad because the performance hit isn't significant enough on today's computers to cause a big hit. Usually it's the construction of huge objects, complexity (i.e. big-O), and various memory issues are the main causes for performance hit. With proper architecture design, you should not even come across any significant performance drop.

With that said, maintainability still outweights performance in terms of business applications, but if you're talking about hardware drivers, or things that require intricate performance gains, then structured C is still the way to go.

Currently CPUs are getting faster and faster, and applications are getting bigger and bigger, and it is the duty of a language to abstract the "how" out of the language and you decide the "what". Let the language worry about performance and implementation. That's another story to be told another time.

 I hope that helps. Do ask more questions. :)

What's your opinion then in event-based programming? If you write a set of business logic (non-UI), event-based and anonymous methods has certain advantages in terms of clean code and more 'asynchronous'. I also wonder in the underlying implementation, what is the impact if these paradigms for clean coding are abused.

 

All these different paradigms are useful for different situations. In my opinion, use what is suited for the current situation. There's no 1 solution for every thing (a general idealist). If you want to talk about business logic, what is evident out there would be something more like BPEL(Business Process Execution Language) or some business logic specific language, which is more suited and flexible in this case. But still, you have to weigh the pros and cons, whether the cost of using BPEL or business processes or contract-based programming or something else is more suited for your current situation.

Event-based programming falls on the concept of an action and a reaction, usually implemented as a loop to detect actions. A reaction is registered as an event to be called when an action happens. How it is registered depends on pointers (if you really want to get into the nitty gritty details). That's the gist of it.

Defining what clean code is very difficult and there isn't really a way right now to determine whether a code is clean or not. A new book just came out called "Beautify Code" probably will explain what you're trying to get here, which probably is about why you should do it one way as oppose to another and how to do it right.

I'm for Domain Specific Languages (DSL) and Software Factories (SF) as a solution to specialize and abstractize your way of coding. What I mean is that not all languages created are suited to do everything, and some times we need an easier syntax to describe a solution, hiding away the complexity and implementation of the underlying solution. Describing, and not solving. Problem with this is that not all of us are language implementors, or even know language theory. Software Factories allow you to abstract and repackage common general solutions and customize it. Together with the help of DSL, customization will be easier.

And I stress again, the software industry is just stalling for time with the amount and level deep abstractions we can do until a better paradigm comes along and blows these countless abstractions away, which will in fact benefit in terms of performance.

More abstractions = deeper heirarchy = not knowing what goes on behind the scenes = potential code abuse.

That's my opinion. :)

If you are truly concerned with performance, you may not even want to go with .NET and CLR facilities.

Having said that, I am pulling out the same horse that has been beaten to death so many times - which is more expensive for your area of application:

1. the cost of the application not being able to compute and carry out its work in a timely manner.
2. the cost of all the developer wages and resources dedicated to build, and then fix/maintain, the application.

Once you have settled the answer for yourself, you should be able to understand why most business applications land up running on higher-layer languages and platforms. Think about it - how many times do you inspect the IL emitted from the VB or C# compiler? And then go ahead to optimize it by hand? You can. But, it is extremely time consuming. Any method to make visualising the computing and data model in the mind easier for the developers will be a cheaper venture.

That of course is not to say one should write abstraction layers that reach the moon. A balance has to be struck, and sometimes you simply have to write arcane code to get acceptable performance from otherwise draggy throughput from easy-to-understannd code. Choose your moments, and document/comment the design decisions clearly.

I am a person for all things simple, but simple can be looked from many angles, from bottom and top down could be totally different story. beautiful unit codes or modules, may form ugly domain view if not properly designed. Event-based programs I feel allows very good decoupling and performance due to possible threading models, especially when business logic allows a lot of parallel logic, it's perfect. Instead of pushing, we are 'pulling' or waiting for events.

 i think it's very hard Domain Specific Languag unless you are able to split it up so cleanly. That said, there aren't many choices of DSL, they are mostly scientific or specialty related like sound, graphics, etc, For business logic, I think it's kinda tough. You may be interested in Domain Driven Design though, the end result is you can have very domain specific classess that can be used like a DSL if done properly. I don't really think of BPEL as a business logic DSL. I do like BPEL, it makes a lot of things easy, Intalio does a pretty good in-memory BPEL engine, but BPEL is purely for orchestration of services rather than describing business logic, there is a subtle difference.

 

My mistake on the BPEL. :)

DSLs are really in the infant stages right now, and it's still trying to figure out itself. I'm very academic if you can't already tell, and DSLs aren't really about what's already out there, but what you can create from it. Tools aren't readily available right now to do something like that easily without a phd. :P

I very much agree with you with regards to event-driven programming, it being clean and all. But I see it as an added feature to a language, much like C# does with events and delegates.

My stand is still, whatever works best for the current situation. :)

does OO really cause slow performance, especially with the hardware we have these days? I think this is just a myth...

Yes, and no. There are still alot of CPUs out there that are only 200mhz or less, with 16mb or even less memory (read 64kb), and these are your everyday appliances. And there's your computers and laptops which can handle it.

Like I said, depends on your situation.

if you building a desktop system or low user count system, then yes, no problems. However, if you are building a system with > 5000 concurrent users, full of transactions, business rules, even saving a couple of CPU clock per code goes a very long way.

I guess the importance is, knowing how to decide what tradeoffs to make during different situations. I come from a world of C++, hence I asked the original question as I am not familiar of how microsoft compile their code into MSIL.

Atlantean:

if you building a desktop system or low user count system, then yes, no problems. However, if you are building a system with > 5000 concurrent users, full of transactions, business rules, even saving a couple of CPU clock per code goes a very long way.

It again boils to whether it is cheaper to add in more RAM or another quad-core CPU or pay a pool of professional performance developers a month's wage to carry out pointer arithmetic and dangerous type & memory manipulation. There are many sites that utilise ASP.NET - the web application runtime for the .NET Framework - to good effect. The easiest example of this would be Microsoft's own ASP.NET community at http://forums.asp.net. There are also many sites, probably more, that use ASP.NET poorly and fail to impress.  The key thing is finding developers who know their platform well enough to wring out every ounce of performance. C++ while inherently closer to the metal is not an instant enabler for performance. Get a greenhorn without an eye for detail, and he most probably is bound to commit some performance drag in C++ as he would in .NET.

I guess the importance is, knowing how to decide what tradeoffs to make during different situations. I come from a world of C++, hence I asked the original question as I am not familiar of how microsoft compile their code into MSIL.

C/C++ get compiled to assembly first before they become the binary machine code, no? Similarly, .NET language compilers emit IL which is an object-oriented assembly language that the CLR "executes". In reality, the CLR invokes the JIT (just-in-time) compiler to compile the code once more into actual machine code for the underlying hardware. These happen on a per-class, per method sequence which on paper looks really slow. There is always that "first hit" delay unless you use ngen.exe to precompile from IL to machine binaries to keep the JIT compiler out of the loop. But the .NET core team have done lots of optimization and tuning to the JIT compiler to make these side-effects as minimal as possible. For most purposes it is best left to the JIT compiler to run on its own so it can perform runtime optimizations based on the actual environment the CLR is operating in, which is not something you can do with ngen.exe.

exactly. if it's cheaper to just add another server to the farm and do some sort of load balancing or round robin between them, that might be more cost effective than trying to wring the last ounce of performance out of your code. the law of diminishing returns is very much applicable to software. a little optimization can yield huge benefits (over not doing any optimization at all) but too much optimization can yield little incremental, if not marginal, improvements.

Ahh, the long feud between performance and Object Oriented. At the end of the day, I believe in fitness for purpose. If your application is meant to crunching "machine" and time-and-mission critical, it's definitely worth it to explore codes via the tradition C or even C++. Now, most of our applications today are complicated enterprise applications or packages, whereby qualities such as maintainability, extensibility and scalability outweighs performance. Now, most applications already come with pre-defined performance requirements, so, imho, meeting those requirements will suffice. At the end of day, what is IT supposed to do - Solve problem, and empower users.

me, i prefer to code a system for maintainability/readability first. then i would profile it to determine bottlenecks and areas that will yield the best improvement for a certain amount of effort. then i go and optimize those sections, then profile again...and continue the cycle until it's sufficiently optimized for its purpose.