If not....why not?
Printable View
If not....why not?
I am somewhat suprised that NO ONE has responded to this question.
Seeing that posts about performance are quite common, I am very curious how people determine a "well performing" application from a "poor" one.....
Hi,
As a student this is not really what we usually care about. Could you please give us an example of what a performance specification might look like? In what unit the performance is measured?
Thanks...
There are usually two domains for basic applications: Resources and Time. If it is a server application (e.g. a WebSite) then Simultainous Access becomes important.Quote:
Originally Posted by Khaled.Alshaya
As a simple (trivial) example consider an application that has a button. A typical performance specification would be that the UI update completes in under 200mS (1/5 of a second). This is a generally accepted perception of "instantly". If the time is longer (thresholds vary, but typically at around 1 second) then it becomes appropriate to show a "Wait Cursor", slightly longer (3-5 seconds) it becomes appropriate to show some type of progress.
During development, this response time would be continuously tested (at each successful build) with records kept to identify any trends where the application is "slowing down". This allows for the appropriate action to be taken BEFORE the application becomes more complex.
Most of the daily processing is not time critical, so that wasn't even part of the design. If the system were to grow exponentially, it might warrant some optimization, but, unless it was specifically quantified, it'd be up to me as to how to implement.
There in lies the problem (based on my experience)...What is the definition of "is not time critical"????Quote:
Originally Posted by dglienna
Is it acceptable to click a button and wait 2 seconds, 3 seconds, ......
At some point the end user will complain, that is guaranteed.
But how do YOU protect yourself against this being considered a "bug"? Or against premature optimization?
I could easly create a silly application with 50 buttons, and have the response time start at 100mS and go up by 100mS (so that the slowest buton took 5.1 seconds). [Randomly arranged]
Give this out to a number of people and have them determine "Which buttons buttons are too slow".
Like using Server Side Grid Controls (DevExpress) for very large datasets, so that it pages the data automatically was a choice I made, even with a few hundred records. Now that there's 2000, it really doesn't matter.
If they ever get to 50K records, it might make a difference.