Factors which effect our application performance
-
Hi, I want to know, what are the major factors which effect our application performance, including all or any.
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
-
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
You forgot
not enough homework
PSoftware rusts. Simon Stephenson, ca 1994.
-
Hi, I want to know, what are the major factors which effect our application performance, including all or any.
-
Hi, I want to know, what are the major factors which effect our application performance, including all or any.
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."
-
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."
RobCroll wrote:
pull on the cowboy boots
To squash bugs in the corners?
-
Hi, I want to know, what are the major factors which effect our application performance, including all or any.
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.
-
Hi, I want to know, what are the major factors which effect our application performance, including all or any.
-
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."
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 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?
-
Hi, I want to know, what are the major factors which effect our application performance, including all or any.
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[^]
-
:) 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."
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.
-
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.
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 aClasscall 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."
-
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 aClasscall 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."