|
Yes. I didn't even do the first call. It is only for exceptions in the UI thread, though ... I don't have a ThreadException handler (all threaded code is self-protected).
|
|
|
|
|
Hello coders
I want to know what will be the main features we have to use to increase application performance. Specially for data updations. There are many available but I want to know the best one.
Any help.
|
|
|
|
|
What kind of app, in witch context, made with witch technology??? Give as more details, in this way it is too generic!
|
|
|
|
|
This really is very generic. You may make use of profiler to see where the loop holes are and then fix them. Since you are speaking of data updations, here are few things to take care of:
1. Connections should be used wisely.
2. Proper indexing.
3. Efficient queries.
"The worst code you'll come across is code you wrote last year.", wizardzz[ ^]
|
|
|
|
|
Don't repost questions. You could simply have updated your other question to clarify it.
|
|
|
|
|
Calling the same method twice will definitely effect performance and response times
"You get that on the big jobs."
|
|
|
|
|
Database related? Reuse Connections, Commands, and Parameters as much as possible -- don't keep instantiating and disposing them.
|
|
|
|
|
I don't think that is quite right. Under the covers, .NET maintains a connection pool so it is best to open the connection, do the work and then close it.
Use using, create the connection, command and parameters. Do the work and get out of there.
"You get that on the big jobs."
|
|
|
|
|
Yes, open and close it, don't dispose of it.
RobCroll wrote: Use using, create the connection, command and parameters
Absolutely not.
|
|
|
|
|
There is not one answer because it depends on what your app is doing - having said that here are 3 things I have learnt from experience.
(1)If you do not need to refresh or send information to a form then don't - screen refreshes are expensive.
(2)If you can sleep a thread then do - looping though a thread waiting for something to happen is expensive.
(3)With reference to 2 above - make your application as event driven as you can so that you are never waiting for something to happen.
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
|
|
|
|
|
|
Hi,
We need frequent data updations in real time updating application like online treading and like these others. I will suggest you to go for dapfor .net grid which is capable in real-time data processing like real-time data updating, real-time data highlighting, real-time data sorting and real -time data filtering.
Cheers,
|
|
|
|
|
Over 52 MILLION Google results for ".net performance best practices"[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
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.
|
|
|
|
|
You forgot not enough homework
P
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
1. Bad design.
2. Bad programming.
3. Inefficient hardware.
"The worst code you'll come across is code you wrote last year.", wizardzz[ ^]
|
|
|
|
|
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?
|
|
|
|
|
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?
|
|
|
|
|
 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.
|
|
|
|
|
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
So instead:
aClass = new aClass()
ClassLib1.DoStuff(aClass)
getData e, f, g, h.
call ClassLib2.DoMoreStuff(aClass)
getData i, j, k, l.
call ClassLib3.EvenMoreStuff(aClass)
getData z
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."
|
|
|
|
|
Looks like a reduction in replicative data retrieval in proc chains.
That has nothing to do with the number of parameters however.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
