Factors which effect our application performance

Pete OHanlon

Badly written code. Lack of knowledge.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

Peter_in_2780

You forgot not enough homework P

Software rusts. Simon Stephenson, ca 1994.

dan sh

1. Bad design. 2. Bad programming. 3. Inefficient hardware.

"The worst code you'll come across is code you wrote last year.", wizardzz[^]

RobCroll

Poor architecture and rigid development environments. Poor architecture speaks for itself. If the architect gets it wrong, no number of builders will fix the problem, the house is going to fall down. Also rigid development environments mean developers are put in there place and not given the freedom to refractor the code. An example I clearly remember was a situation where a number of methods were passing many parameters and requesting the same data multiple times. By encapsulating the parameters, the methods became a lot more maintainable and only had to do the work once. This is not something an architect is in a position to envisage. Senior developers need the freedom to pull on the cowboy boots from time to time. They also need to keep an open mind and an open door to junior developers.

"You get that on the big jobs."

PIEBALDconsult

RobCroll wrote:

pull on the cowboy boots

To squash bugs in the corners?

Ravi_Alienware

But after any code performance some other things also matter like : put huge data into session like multiple tables. And all the repeated images which I want to show on our application, may not be done cached.

jschell

In general. 1. Requirements - most impact 2. Architecture 3. Design 4. Implementation - least impact For some limited domains there can be differences in the above. For example embedded device drivers could see performance impacts due to the last item.

jschell

RobCroll wrote:

An example I clearly remember was a situation where a number of methods were passing many parameters and requesting the same data multiple times. By encapsulating the parameters, the methods became a lot more maintainable and only had to do the work once. This is not something an architect is in a position to envisage.

And by doing only that by what percentage was the performance of the application reduced?

RobCroll

:) It didn't reduce performance, it improved it. Didn't benchmark the change but it reduced requests to the database by approx 66%

"You get that on the big jobs."

robertalis

Hello, If we talk about real time we can perform various data processing in real time like data updating, data highlighting, data sorting, data filtering and data grouping which is application based. I will suggest you a custom component, which will help you to increase your application performance http://www.dapfor.com/Feature.aspx?id=performance[^]

jschell

Requests? Not sure I undestand that. If I call a proc with one param or 50 the proc call itself is still singular. Now in might be that the driver uses more IP packets for more parameters but if that is significant then one might look for another driver and even another database. And certainly one would reduce all procs to use a minimal number of params or none. So in that case it would not be a lot but rather that it was using any at all.

RobCroll

Can't really give a code snippet but to give an idea

call ClassLib1.DoStuff(a, b, c, d)
getData e, f, g, h.
call ClassLib2.DoMoreStuff(a, b, c, d, e)
getData i, j, k, l.

  call ClassLib3.EvenMoreStuff(a, b, c, d, e, f)
             getData i, j, k, z //Hang on we already got most of this in DoMoreStuff

So instead:
aClass = new aClass() //Add a, b, c, d
ClassLib1.DoStuff(aClass)
getData e, f, g, h.
//Add e, f, g, h to aClass

  call ClassLib2.DoMoreStuff(aClass)
             getData i, j, k, l.
             //Add i, j, k, l to aClass

  call ClassLib3.EvenMoreStuff(aClass)
             //don't need to getData i, j, k we already have it
             getData z 
             //Add  to aClass

Now you can start avoiding hammering resourses and for me at least, ClassLib3.EvenMoreStuff(a, b, c, d, e, f, z) is not the most maintainable code. Hope that makes sense

"You get that on the big jobs."

jschell

Looks like a reduction in replicative data retrieval in proc chains. That has nothing to do with the number of parameters however.